Get full details for a specific MCP server. Pass the server name (e.g. "GitHub", "Brave Search"), registry ID slug, or endpoint URL. Returns score, state, tools list, latency, and recent test history.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Server name, registry ID slug, or any identifier (e.g. "github", "brave-search", "gateway-pipeworx-io-rpc-mcp") | |
| url | No | The MCP server endpoint URL (e.g. "https://mcp.example.com/mcp") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return values (score, state, tools list, latency, test history), which is adequate for a read operation. Lacks info on authentication or side effects, but not critical for this tool.
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 concise sentences: first states purpose, second covers inputs and outputs. No unnecessary words. Front-loaded and efficient.
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?
No output schema, but description adequately lists return fields (score, state, tools list, latency, test history). Parameters are covered. Error handling not mentioned, but for a simple get tool, this is acceptable.
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% with descriptions for both parameters. Description adds examples (e.g., 'GitHub', 'Brave Search') and clarifies that id can be a name or slug, but does not significantly extend beyond schema. 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?
Description clearly states the verb 'Get' and resource 'full details for a specific MCP server'. It lists the return contents, distinguishing it from siblings like query_registry, recommend_server, and report_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?
Implies usage when full details of a specific server are needed, but does not explicitly state when not to use or compare with alternatives. However, the context is clear and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a distinct purpose: retrieving details, searching, recommending, and reporting. There is no overlap or confusion between them.
All tools follow a consistent verb_noun pattern (get_server, query_registry, recommend_server, report_server) with no mixing of styles.
Four tools is a well-scoped set for a registry server. Each tool covers a necessary operation without being too few or too many.
The tool set covers the core registry operations: retrieving details, searching, getting recommendations, and reporting. No obvious gaps for an agent's interaction with the registry.
