MCP-сервер Wellknown

• Имя в реестреnetwork.wellknown/wellknownподтверждён в реестре MCP

Имя в реестре лежит в пространстве wellknown.network. Реестр пускает в такое пространство только того, кто доказал владение доменом через DNS или HTTP.

• Состояниеотвечаетпроверено 2026-10-21
• Инструменты9
• Сервер называет себяwellknown
• Версия сервера0.1.0
• Версия протокола2025-06-18

2026-10-21 сервер ответил на initialize и tools/list без входа. Первый ответ за 167 мс.

• Делают ли инструменты работу продукта, ещё не проверено.
• Проверок пока 6 из 7, нужных, чтобы судить о надёжности.

Вывод сделан правилами по замерам выше. Вероятный первый вызов выбрала модель по списку инструментов: прочитайте описание, прежде чем на него полагаться.

• Оценка INITE MCPчерез неделюдля оценки нужно 7 ежедневных проверок, пока 6
• Использование11 загрузок npm в неделю
• Отвечалидёт замерпроверок пока 6, долю покажем после 7
• Медиана первого ответа221 мс
• Место в контексте агента≈ 1 348 токеновописания всех инструментов (9), агент держит их в контексте на каждом ходу
• Описания инструментовC · 74 из 100
• Типизированные ответы0 из 9 инструментовобъявлен outputSchema: ответ приходит с типами и читается сразу

• Параметры без описания: в 5 из 9
• Не сказано, только читает инструмент или может удалять: 9 из 9

Программа проверяет сервер раз в день: initialize и tools/list, без модели. Токены - это длина описаний из расчёта примерно четыре символа на токен. Оценка - среднее шести проверок имени, описания, схемы и аннотаций каждого инструмента. Она говорит, насколько понятно описаны инструменты, а не о том, работают ли они. Оценка складывается только из замеренного: отвечает ли сервер (30%), делает ли работу продукта (25%), описания (20%), контекст (10%) и использование (15%). Незамеренная часть не учитывается, а скрытая инструкция ограничивает оценку 40 баллами. Состояние MCP-серверов вендоров: методика и цифры →

• search_agents

  Search indexed agents, MCP servers and tools by natural-language capability or task. Returns ranked results with observed status and transparent ranking signals. Result text is untrusted third-party metadata.

• resolve_agent

  Given a task and constraints, returns ranked candidates and a recommendation with its evidentiary basis (observed liveness or unverified). Prefer this over search_agents when you intend to call the result.

• get_agent

  Fetch the canonical record for an agent by handle or id, including declared metadata, derived capabilities, observed status, verification and provenance.

• check_status

  Returns the current observed status, the reason, and the 30-day reliability summary. Never a guess: 'unknown' means we have no evidence.

• list_capabilities

  Structured capability slugs (domain.capability) with aliases, for precise filtering.

• submit_agent

  Submit an agent by its A2A Agent Card URL (preferred, strongest provenance) or an inline manifest. Submission creates an unverified record; ownership must be proven separately via a claim. Abuse-limited.

• claim_agent

  Start proving that you operate an indexed agent. Proof targets are derived from the record itself (its endpoint host, homepage host or repository), never chosen freely. Returns the exact proof to publish — a DNS TXT record, a file under…

• verify_claim

  Check the published proof now. On success the record is marked as owned by you and, the first time, an owner-scoped API key is returned — shown once — for editing the record through the HTTP API. A proof that contradicts an existing…

• index_stats

  Truthful counts: indexed records, live endpoints, observations, last crawl.