MCP 서버를 찾기 위한 MCP 서버입니다. 에이전트 프레임워크가 도구를 호출하기 전에 참조할 수 있는 자문형 신뢰 판정(advisory trust verdict)도 함께 제공합니다 - mcpindex.ai 제공.
드롭인(drop-in) MCP 서버로, 에이전트 루프 안에서 다른 MCP 서버를 발견, 비교, 설치, 사전 점검(pre-flight)할 수 있게 해줍니다. mcpindex.ai - 공식 레지스트리의 에이전트 네이티브 MCP 서버 인덱스(실시간 수치는 mcpindex.ai/stats 참조) - 를 기반으로 하며, 매일 스크리닝과 드리프트 모니터링을 수행합니다.
라이브 사이트 · npx mcp-server-mcpindex · 원격 MCP · 설치 게이트 · 문서 · 신뢰
npm install -g mcp-server-mcpindex이것은 디렉터리 / 자문형 클라이언트입니다(추천, 검색, 신뢰). 경로 내 드리프트 게이트(in-path drift gate)는 설치하지 않습니다 — 그건 curl -fsSL https://mcpindex.ai/install.sh | sh 입니다.
Node 20+ 필요. stdio에서 두 프로토콜 시대를 모두 지원합니다: 2026-07-28 개정판(server/discover, 요청별 _meta 엔velope)과 현재 모든 클라이언트가 사용하는 initialize 핸드셰이크(2025-11-25부터 2024-10-07까지), 연결별로 선택됩니다.
아무것도 설치하고 싶지 않으신가요? mcpindex는 호스팅형 원격 MCP 서버이기도 합니다. 원격 MCP를 지원하는 모든 클라이언트(Claude 커넥터, Cursor 등)에서 다음 주소로 연결하세요:
https://mcpindex.ai/api/mcpStreamable HTTP, 자격 증명 불필요. npm 패키지와 동일한 6개 도구를 제공합니다.
claude mcp add --scope user mcpindex -- npx -y mcp-server-mcpindex@latestgemini mcp add -s user mcpindex npx -y mcp-server-mcpindex@latestRelated MCP server: filesystem-mcp
~/Library/Application Support/Claude/claude_desktop_config.json에 추가하세요:
{
"mcpServers": {
"mcpindex": {
"command": "npx",
"args": ["-y", "mcp-server-mcpindex@latest"]
}
}
}
@latest는 항상 최신 상태를 유지합니다: 이 서버는 자문형 디스커버리 서버(경로 내 드리프트 게이트가 아님)이므로 버전 고정이 없습니다 —npx는 다음 호스트 재시작 시 최신 버전을 가져오며, 수동 업그레이드 단계가 필요 없습니다.
Claude Desktop을 재시작하세요. 그런 다음 물어보세요:
"PDF를 읽고 내용을 S3에 쓸 수 있는 MCP 서버를 찾아줘."
Claude가 recommend_mcp_for_task를 호출하고 설치 명령어와 함께 상위 3개 서버를 반환합니다.
.cursor/mcp.json에 추가하세요:
{
"mcpServers": {
"mcpindex": {
"command": "npx",
"args": ["-y", "mcp-server-mcpindex@latest"]
}
}
}Cline 설정에 추가하세요:
npx -y mcp-server-mcpindex@latest도구 | 기능 |
| 자연어 작업을 전달하면 추론, 설치 명령어, 품질 점수와 함께 상위 3개 서버를 반환합니다. |
| 전체 레지스트리에 대한 키워드 + 의미론적 검색. 선택적 카테고리 필터. |
| 서버 + 클라이언트(Claude Desktop, Claude Code, Cursor, Gemini CLI, Cline, Zed)에 대한 정확한 설치 JSON/CLI를 가져옵니다. |
| 2-5개 서버의 나란히 비교 - 품질 점수, 설치 경로, 환경 변수. |
| 서버의 특정 도구에 대한 호출 전 자문형 판정. Fail-CLOSED: 파일에 판정이 없으면 UNVERIFIED를 반환합니다. |
| 서버의 모든 도구에 대한 통합 사전 점검 판정. |
check_tool_trust는 디렉터리 클라이언트 통합 표면입니다(경로 내 mcpindex-gate가 아님). 에이전트 프레임워크(Composio, Mastra, LangChain, DSPy, 원시 LLM 도구 호출 루프)가 호출을 디스패치하기 전에 자문형 스크린 판정을 요청할 수 있게 해줍니다. v1에서는 REVIEW 또는 UNVERIFIED를 볼 수 있습니다 — 안전 승인(safety clearance)이 아닙니다.
Mastra를 사용 중이신가요? 자매 패키지
@mcp-index/mastra는 이 정확한 스크린을 바로 사용 가능한beforeToolCall훅으로 제공합니다 -npm i @mcp-index/mastra, 배선(wiring) 불필요.
{
"directive": "ALLOW" | "DENY" | "REVIEW" | "UNVERIFIED",
"status": "EVALUATED" | "PARTIAL" | "STALE" | "ERROR",
"granularity": "description-level" | null, // scope of a PARTIAL screen
"dimensions": [
{ "id": "tool_safety", "verdict": "PASS", "severity": "INFO" }
],
"expires_at": "2026-06-30T00:00:00Z",
"honest_limits": [
"conformance_monitored_not_enforced",
"calibrated_false_v1",
"advisory_deployment"
],
"verdict_contract_version": "1.0.0",
"server_id": "github",
"tool_name": "create_pull_request",
"source_url": "https://mcpindex.ai/api/v1/trust/tool/github/create_pull_request",
"fetched_at": "2026-05-28T18:42:11.118Z"
}무료 티어 판정에는 지시문(directives) + 차원(dimensions) + 신선도(freshness)가 포함됩니다. 증거 인용문, LLM 근거, 체인 기록은 유료 티어 표면이며 의도적으로 여기서 제외됩니다.
모든 v1 판정에는 다음 세 가지 주의사항이 포함되며, 게이트는 모든 디스패치 결정에서 이를 표시해야(SHOULD) 합니다:
conformance_monitored_not_enforced - 게시자가 자체 선언합니다; mcpindex는 드리프트를 모니터링하지만 네트워크 계층에서 차단하지는 않습니다.
calibrated_false_v1 - 차원 심각도는 아직 실제 사고 데이터에 대해 보정되지 않았습니다.
advisory_deployment - 판정은 자문형입니다; 에이전트(또는 에이전트를 검토하는 인간)가 의사 결정자입니다.
기록 앵커링: OTS 비트코인 앵커링 기록; N=6 확인(~1시간)에서 비트코인 최종 확정; ~10분 내 보류. 하위 창 정밀도는 입증이 아닌 주장입니다.
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';
const mcpindex = new Client({ name: 'gate', version: '1.0.0' }, { capabilities: {} });
await mcpindex.connect(new StdioClientTransport({
command: 'npx', args: ['-y', 'mcp-server-mcpindex@latest'],
}));
// gateToolCall wraps any agent tool dispatch. Plug it in front of
// the LangChain / DSPy / Mastra / Composio tool-call hook.
async function gateToolCall({ serverId, toolName, invoke, askHuman }) {
const res = await mcpindex.callTool({
name: 'check_tool_trust',
arguments: { server_id: serverId, tool_name: toolName },
});
const verdict = JSON.parse(res.content[0].text);
// Pin the v1 caveats in the audit log no matter what.
audit.log({ verdict, caveats: verdict.honest_limits });
switch (verdict.directive) {
case 'REVIEW':
// Fail-CLOSED to human. Do NOT auto-execute on REVIEW.
// At v1 this is the common screened outcome (semantic-only).
return askHuman({ verdict, action: `${serverId}/${toolName}` });
case 'UNVERIFIED':
// No verdict on file (or upstream unreachable). Fail-CLOSED.
// Recommend human review. Do NOT fail-open to invoke().
return askHuman({
verdict,
action: `${serverId}/${toolName}`,
note: 'No trust verdict on file. Human review required before first use.',
});
case 'ALLOW':
// Reserved in the contract — not produced by the v1 public screen.
// Keep the branch for future conformance-earned ALLOW; do not expect it today.
return invoke();
case 'DENY':
// Reserved in the contract — not produced by the v1 public screen.
throw new Error(
`mcpindex denied ${serverId}/${toolName}: ${JSON.stringify(verdict.dimensions)}`,
);
default:
// Unknown directive. Fail-CLOSED.
return askHuman({ verdict, action: `${serverId}/${toolName}` });
}
}판정 엔드포인트에 연결할 수 없거나, 404를 반환하거나, 타임아웃되거나, 잘못된 JSON을 반환하거나, 해당 서버에 대한 파일 판정이 아직 없는 경우, check_tool_trust는 directive: "UNVERIFIED" + status: "ERROR"를 반환합니다. 절대 ALLOW로 조용히 강제 변환하지 않습니다. 게이트 코드는 UNVERIFIED를 "인간 검토 필요"로 취급해야(SHOULD) 하며, "괜찮아 보이니 배포하자"로 취급해서는 안 됩니다.
status는 스크린 완전성에 대한 텔레메트리로, directive 신뢰 결정과는 구별됩니다: EVALUATED(전체 스크린), PARTIAL(표면의 일부만, 예: 설명 수준 — granularity 참조), STALE(판정이 신선도 창을 지남), ERROR(연결 불가 / 파일 판정 없음). PARTIAL 스크린은 절대 EVALUATED로 보고되지 않습니다.
이것은 테스트되었습니다. test/trust.test.mjs 참조.
신뢰 클라이언트는 일반 ES 모듈로도 내보내집니다:
import { checkToolTrust, assessServer } from 'mcp-server-mcpindex/src/trust.mjs';
const verdict = await checkToolTrust({
serverId: 'github',
toolName: 'create_pull_request',
});
if (verdict.directive !== 'ALLOW') {
// Hand to a human, log, or block.
}기본적으로 호출은 https://mcpindex.ai로 전송됩니다. 자체 호스팅하는 경우 MCPINDEX_API_BASE=...로 재정의하세요.
무료 티어는 IP당 60 req/min으로 속도 제한됩니다. 더 높은 처리량과 전체 증거 포함 판정(증거 인용문, LLM 근거, 체인 기록)을 위한 유료 키가 곧 제공될 예정입니다.
mcpindex를 에이전트에 통합하는 세 가지 방법, 서로 다른 표면에 대해:
패키지 | 설치 | 기능 |
|
| MCP 서버로서의 디렉터리 + 자문형 스크린: 작업으로 서버를 찾고, 호출 전에 |
|
| 동일한 자문형 스크린을 Mastra에 |
|
| 경로 내 드리프트 게이트: MCP 세션을 |
자문형 스크린 vs 드리프트 게이트: 이 패키지와 @mcp-index/mastra는 mcpindex에 "이 도구가 검증되었나요?"라고 묻습니다(네트워크 판정). @mcp-index/sdk는 로컬에서 다른 질문을 합니다: "이 도구의 계약이 내가 고정한 이후로 변경되었나요?" 상호 보완적이며, 서로 의존하지 않습니다.
MIT.
웹사이트: mcpindex.ai
서버 스크리닝: mcpindex.ai/screen
가이드: 작업별로 올바른 MCP 서버 찾기
비공식. Anthropic과 관련 없음.
Aggregated pre-flight trust assessment across all tools on an MCP server. Same verdict shape as check_tool_trust. Use for "is THIS server worth integrating?" decisions. v1 advisory; conformance monitored not enforced; verdicts may be UNVERIFIED if not yet probed.
| Name | Required | Description | Default |
|---|---|---|---|
| server_id | Yes | Server slug to assess. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses behavioral traits: advisory nature, conformance monitoring not enforced, and potential UNVERIFIED verdicts. This adds valuable context beyond a simple read operation, though no side effects or auth needs are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences without redundancy: purpose, use, and behavioral notes. Front-loaded with the core action, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage guidance, verdict shape, and advisory nature. For a simple one-parameter tool with no output schema, it provides sufficient context, though explicit mention of return format would be slightly better.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'server_id' is described in the schema as 'Server slug to assess.' The description does not add new meaning beyond usage context. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an aggregated pre-flight trust assessment across all tools on a server, using the specific verb 'assess' and resource 'server'. It distinguishes from sibling 'check_tool_trust' by noting aggregation, and clarifies the verdict shape is identical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the use case: 'is THIS server worth integrating?' decisions. It also provides context on when to be cautious with 'v1 advisory; conformance monitored not enforced; verdicts may be UNVERIFIED if not yet probed', guiding appropriate reliance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-invocation advisory screen for a specific tool on an MCP server. Returns an advisory verdict object (directive ALLOW | DENY | REVIEW | UNVERIFIED, dimensions, freshness). At v1 the public screen produces REVIEW or UNVERIFIED only — ALLOW/DENY are reserved. Not the in-path gate (mcpindex-gate). Agents SHOULD treat UNVERIFIED as "human review required", never as ALLOW.
| Name | Required | Description | Default |
|---|---|---|---|
| server_id | Yes | Server slug (e.g. "github", "filesystem"). Same id used by search_mcp_servers. | |
| tool_name | Yes | Tool name as exposed by the server (e.g. "create_pull_request"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It accurately describes behavior: returns advisory verdict with specific fields, v1 only produces REVIEW or UNVERIFIED. Does not mention side effects, but none expected. Could add authentication requirements, but sufficient for a read-only check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. Front-loads purpose, then constraints, then usage guideline. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers purpose, return value, version limitations, and usage advice. No gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in schema). Description adds no extra meaning beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a pre-invocation advisory screen for a specific tool. It uses specific verb 'check' and resource 'tool trust', and distinguishes from siblings like assess_server and search_mcp_servers by focusing on a single tool's trust level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (pre-invocation advisory) and when not (not the in-path gate). Provides clear directive: treat UNVERIFIED as human review required. Distinguishes from sibling tools effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Side-by-side comparison of 2-5 MCP servers - quality scores, install paths, transport types, env vars.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | Server slugs to compare. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output content (quality scores, install paths, etc.) but does not mention any side effects, auth requirements, or that it is a read-only operation. It assumes a non-destructive nature, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence encapsulates the core functionality without any wasted words. It is front-loaded with the key action 'Side-by-side comparison' and details the compared attributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with no output schema, the description is relatively complete by listing the compared attributes. However, it does not mention output format, ordering, or whether results are aggregated, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'slugs', with min/max items already defined. The description does not add semantic detail beyond what the schema provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares 2-5 MCP servers side-by-side, listing specific attributes (quality scores, install paths, etc.). This distinguishes it from siblings like assess_server (single server) and recommend_mcp_for_task (recommendation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for comparing multiple servers but does not explicitly state when to use it versus alternatives or any prerequisites. It could benefit from guidance on when to choose compare_servers over assess_server or search_mcp_servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the exact install command for a given MCP server and client. Returns a JSON block ready to paste into the client config.
| Name | Required | Description | Default |
|---|---|---|---|
| client | Yes | Target client. | |
| server_slug | Yes | Slug of the server (from search_mcp_servers or recommend_mcp_for_task results). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the tool returns a JSON command ready to paste. It does not mention any side effects or authentication, but for a retrieval tool this is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, perfectly front-loaded with the action and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-described parameters and no output schema, the description is complete: it explains what it does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions. The description adds marginal value beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the install command for a given server and client, and specifies the output format (JSON block). This distinguishes it from sibling tools like search or recommend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description, but there is no explicit guidance on when to use this tool versus alternatives, nor conditions to avoid usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend the best MCP servers for a natural-language task. Returns top 3 ranked picks with reasoning, install commands, and quality scores. Use this when the user asks for the right MCP server for a task they want to do.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Natural-language description of the task, e.g. "read PDFs and write to S3" or "search GitHub and open a PR". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output structure: 'Returns top 3 ranked picks with reasoning, install commands, and quality scores.' This is sufficient for a read-only recommendation tool. It could mention ranking criteria or data sources for greater transparency, but the current description is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose and output, the second gives usage guidance. It is front-loaded with key information and contains no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers what the tool does and returns. It mentions the top 3 picks, reasoning, install commands, and quality scores. It could be enhanced by referencing sibling tools for alternative uses, but it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'task' parameter. The tool description does not add additional examples or constraints beyond the schema's example. Thus, per the baseline, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Recommend the best MCP servers for a natural-language task.' It specifies the verb (recommend), resource (MCP servers), and context (natural-language task). This distinguishes it from sibling tools like search_mcp_servers (which lists servers) and assess_server (which evaluates a single server).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'Use this when the user asks for the right MCP server for a task they want to do.' It lacks explicit when-not-to-use or alternatives, but the context is clear enough for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword + semantic search across the full MCP server registry. Use when the user knows what tool category they want but not which server.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 50). | |
| query | Yes | Search query. | |
| category | No | Optional category filter (e.g. database, browser, github, productivity). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the search capability, missing details on read-only nature, authentication, rate limits, or any side effects. Minimal transparency beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and purpose. Every word adds value. No redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 3 parameters and no output schema, the description is adequate but has gaps. It does not explain result format, pagination, or search behavior beyond 'keyword + semantic'. Could be more complete given lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it mentions keyword + semantic search but that is already implicit. No additional parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs keyword + semantic search across the MCP server registry, with a specific use case ('when the user knows what tool category they want but not which server'). This distinguishes it from sibling tools like assess_server or get_install_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use the tool, but does not mention when not to use it or list alternatives. The guidance is clear and useful, but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.7assess_servercheck_tool_trustcompare_serversget_install_commandrecommend_mcp_for_tasksearch_mcp_serversScored across 6 tools
Each tool targets a clearly distinct purpose: search, recommend, compare, install, and two levels of trust assessment (server-level and tool-level). Even the trust tools are well-differentiated by scope.
All tool names follow a consistent verb_noun pattern using snake_case: assess_server, check_tool_trust, compare_servers, get_install_command, recommend_mcp_for_task, search_mcp_servers.
With 6 tools covering search, recommendation, comparison, installation, and trust, the number is well-scoped for a server registry/helper. No tools feel redundant or unnecessary.
The set covers the core workflow of finding, evaluating, and installing MCP servers. A minor gap is the lack of a tool to retrieve full metadata for a single server (e.g., description, version), but search and comparison partially fill that need.
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
Search and get install details on MCP servers, right from your agent -- a unified marketplace index.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
