Server Quality Checklist

Tool Scores

• adminB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names actions and notes that params carries arguments, but does not reveal that actions like unregister, migrate, and restore are likely mutating or potentially destructive, nor does it mention permissions or side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the purpose statement, followed by an efficient action list. It contains no padding, though for eight actions it could benefit from additional detail without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a multi-action admin tool with a minimal schema and no annotations, so the description must compensate. It lists actions and explains the params pattern but fails to specify per-action input requirements, effects, or prerequisites, leaving the agent without enough information to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the schema provides no enum for action and only a generic object for params. The description adds the valid action values and explains that params carries the action's arguments, which is helpful but insufficient; it does not document what parameters each action expects.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states "Manage the warden registry" and enumerates eight concrete actions, making the tool's purpose and scope clear. This clearly distinguishes it from siblings such as search, call_tool, use_skill, and route, which focus on other operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for warden registry management through the action list, but does not explicitly state when to use this tool versus alternatives. It does not mention exclusions or address possible overlap with the sibling 'route' tool for routing-related actions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• call_toolA
  3.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description must disclose behavioral traits, but it only says 'Invoke a downstream MCP tool' without mentioning side effects, safety, permissions, error behavior, or whether the call is synchronous. The potential for executing arbitrary tools is a significant transparency gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, both packed with relevant information. The first sentence states the purpose, the second adds essential parameter source context. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a generic invoker with no output schema and no annotations. The description covers the core purpose and parameter source but does not describe return values, error handling, or the behavior of the invoked tool. For a tool that can execute arbitrary downstream MCP tools, more guidance is needed to be considered complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must add meaning. It does clarify that server and name come from a search result of type 'tool', which helps. However, it omits any explanation of the 'arguments' parameter, even though the schema only shows it as an object/null. This partial compensation justifies a mid-range score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Invoke') and resource ('a downstream MCP tool'), clearly distinguishing it from siblings like 'search' by explicitly saying the tool is found via search. It leaves no ambiguity about what action is performed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The second sentence gives clear context on when to use this tool: after a search, using server and name from a result of type 'tool'. This implies when it is appropriate, but it does not explicitly state when not to use it or mention alternatives like use_skill or route, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• use_skillA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden. It states that the tool loads full instructions, implying a read-only operation, but does not disclose any edge cases, errors, or prerequisites beyond referencing `search`. This meets the minimum threshold but lacks deeper behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no filler or redundant information. It front-loads the core action and resource, making it highly concise and structurally effective.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, but the description lacks explicit parameter clarification and does not explain the role of the loaded instructions (e.g., how they relate to `call_tool`). Given the sibling tools and output schema, more context about the returned instructions could enhance completeness, but the description is minimally adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero description coverage for the single 'name' parameter. The description only indirectly implies that 'name' refers to a skill found via search, but it does not explicitly define the content or format of the parameter, nor state that it should be the exact name from search results.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Load the full instructions') on a specific resource ('a Skill'), and references the sibling tool 'search' to distinguish its role from searching. It directly addresses what the tool does and how it fits with related tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrasing 'found via `search`' clearly implies the intended workflow: first use `search`, then `use_skill` to load details. It does not explicitly state when not to use this tool or mention alternatives, but the context is sufficient for an agent to infer appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• searchA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions return behavior ('Returns up to limit matching entries each with a type'), and describes how to act on results, but it does not explicitly state that the operation is read-only or discuss error/pagination behavior. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with the core purpose, and succinctly adds usage guidance. Every sentence serves a role with no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a straightforward search operation, output schema exists, and the description covers the query capabilities, limit behavior, and follow-up action (call_tool/use_skill). No significant gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds meaning beyond the schema by explaining that 'query' can be a name, description, or regex, and that 'limit' controls the maximum number of returned entries. Since schema coverage is 0%, this semantic clarification is valuable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Search available MCP tools and Skills by name, description, or regex.' It uses a specific verb ('Search') and resource ('MCP tools and Skills'), and distinguishes from siblings by explaining that results should be consumed via call_tool or use_skill.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly defines when to use this tool (for discovery) and explicitly directs the agent to use call_tool or use_skill for invocation. It does not list exclusions or alternatives explicitly, but provides clear contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• routeA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool has no side effects ('NEVER executes anything'), describes the return shape ('selection (`chosen` / `candidates`)'), and clarifies the limits of `context` to 'light file metadata', preventing misuse. This is strong transparency for a routing-only tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences and every clause earns its place. The first sentence states the core purpose, and the second packs the critical non-execution caveat plus parameter clarifications without unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has an output schema and no annotations, the description covers all key elements: purpose, non-execution behavior, return indication, parameter semantics, and how to proceed with siblings. It is sufficiently complete for an agent to decide when to call it and what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It does: `task` is the routing input, `context` is clarified as 'optional light file metadata' with `file_path`/`extension` references, and `mode` is explained as overriding the configured auto/ask default. This adds meaningful semantics beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Pick') and identifies the resource ('best tool or skill for `task`'), clearly distinguishing it from executing tools by stating it 'NEVER executes anything'. It also implies a comparison/ranking role via 'ranked by server-side routing config', which separates it from siblings like `call_tool` and `use_skill`.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  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 (to select a tool/skill for a task) and provides clear alternatives: 'invoke the pick yourself via `call_tool` or `use_skill`'. It also documents optional parameters (`context`, `mode`) and their purpose, giving actionable guidance for invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.