Server Quality Checklist

Tool Scores

• web_searchA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and it delivers meaningful context: it discloses the underlying services (Tavily, Firecrawl), the default model (GLM-5.2 via Ark), and even the caching behavior via the 'cached' flag. This goes beyond a simple 'search tool' and gives the agent insight into how results are generated and possibly stale.

  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 well-structured: a purpose sentence followed by a bulleted return list. The return list is necessary because no output schema exists, and each bullet earns its place. It is slightly more verbose than necessary but remains focused and front-loaded with the main function.

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

  Completeness4/5

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

  The description covers the search pipeline, default model, return values, and caching, and it links to a sibling tool (get_sources) via session_id. With no output schema, this is essential. It does not provide explicit alternatives for search-related choices (gemini_search), but that gap is primarily for usage guidelines. Overall, the description is reasonably complete for a read-only search tool with a rich schema.

  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 100%, so the schema already explains all three parameters clearly. The description adds little to parameter understanding, though it does connect the returned session_id to get_sources, which is output-related. Baseline 3 applies per the rubric.

  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 'performs a deep web search' using Tavily + Firecrawl and synthesizes a cited answer with an LLM. This specific pipeline (multi-source + synthesis) distinguishes it from siblings like gemini_search, which likely uses a different search mechanism.

  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 phrase 'deep web search' implies when to use it, and the return field 'pass to get_sources' suggests a workflow. However, it does not explicitly state when to use this tool versus alternatives like gemini_search, web_fetch, or web_map, nor does it mention any exclusions.

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

• web_fetchA
  4/5.0
  Behavior4/5

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

  With no annotations, the description discloses important behavioral details: full content extraction, Markdown conversion, 100% fidelity, limitations with dynamically loaded JavaScript content, and processing time for large pages. This adds significant value beyond the basic fetch operation and is more transparent than typical descriptions.

  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 well-structured with clear sections and bullet points, making it scannable. It is appropriately sized for the complexity, but there is minor redundancy (e.g., URL accessibility is mentioned in both the schema and the description), which prevents a perfect score.

  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 one parameter and no output schema, the description covers key aspects comprehensively: what it extracts, how it converts, fidelity, edge cases (auth, dynamic content, page size). This is sufficient for an agent to understand when and how the tool behaves, including expected return format (Markdown).

  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?

  The schema description covers the single 'url' parameter 100%, so the baseline is 3. The tool description reinforces that the URL must be 'complete and accessible' but does not add new semantic details beyond what the schema already states. No ambiguity or missing parameter information.

  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 ('Fetches and extracts complete content') and names the resource ('a URL') and the outcome (returning structured Markdown). This clearly distinguishes it from sibling tools like web_search (search) and web_map (map).

  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 usage: fetching a specific URL's content. It provides edge cases and best practices but does not explicitly state when to use this tool over other siblings like web_search, nor does it mention exclusions or alternatives. The context is clear but not explicit about selection criteria.

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

• web_mapA
  4.2/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the burden of explaining behavior. It discloses graph traversal, configurable depth and breadth, instruction filtering, and potential timeout issues for large sites. This adds meaningful context beyond the schema, though it does not cover authentication or error handling.

  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 well-structured with a clear opening statement, key features in bullet points, and a separate best practices section. It is concise, front-loaded, and every sentence adds value without excessive verbosity.

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

  Completeness4/5

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

  The description covers the core functionality, configuration controls, and practical edge cases (timeouts, filtering). Since an output schema exists, the lack of return value details is acceptable. The description is complete enough for an agent to understand how to deploy and tune the tool effectively.

  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 schema already covers all parameters with descriptions, so the baseline is 3. The description enhances this by explaining how to use max_depth and instructions in practice (e.g., 'Start with low max_depth (1-2) for initial exploration'), adding value beyond the schema's bare parameter definitions.

  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 purpose: 'Maps a website's structure by traversing it like a graph, discovering URLs and generating a comprehensive site map.' This is specific and distinct from sibling tools like web_fetch or web_search, which focus on fetching individual pages or searching the web.

  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 provides practical usage tips such as starting with low max_depth (1-2) and using instructions to filter content. However, it does not explicitly mention when to choose this tool over alternatives or when not to use it, so the guidance is implied rather than explicit.

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

• get_sourcesA
  4.4/5.0
  Behavior4/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 discloses that the tool returns a 'full source list' from 'cached sources', implying a read-only operation. It does not discuss potential failure modes or session validity, but for a simple retrieval tool it provides sufficient behavioral context about what the agent can expect.

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

  Conciseness3/5

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

  The description is spread across three sentences with notable redundancy: 'session_id returned by web_search' appears in all three, and the first sentence is verbose and contains a typo ('the this tool'). It could be condensed to one or two sentences without losing meaning.

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

  Completeness4/5

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

  For a simple one-parameter tool with an output schema, the description adequately covers what the tool does, when to use it, and how to provide input. It does not describe error scenarios, but those are not critical for basic usage. The sibling tools are distinct enough that confusion is unlikely.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explicitly stating the session_id's provenance ('returned by web_search') and its purpose ('to get the full source list'). This reinforces the schema description and helps the agent understand how to obtain and use the parameter.

  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 'Retrieve all cached sources for a previous web_search call', a specific verb+resource. It distinguishes itself from sibling tools by explicitly linking to web_search and mentioning 'session_id returned by web_search'. The purpose is unequivocal and not a tautology.

  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 first sentence provides an explicit trigger: 'When you feel confused or curious about the search response content, use the session_id returned by web_search to invoke this tool'. This tells the agent exactly when to use the tool, and the repeated reference to 'previous web_search call' clarifies that it is not for initiating new searches, distinguishing it from web_search.

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

• gemini_searchA
  4.5/5.0
  Behavior4/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 discloses the search mechanism, output type (grounded answer plus citations), independence from other tools, and API key requirement. However, it lacks details on rate limits, error handling, or what happens if the API key is invalid.

  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 three sentences, each serving a distinct purpose: function, differentiation/use case, and setup requirement. No fluff, front-loaded with the core purpose.

  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?

  Despite missing output schema details, the description covers purpose, usage context, and authentication. The tool is simple with one parameter, and the description provides enough for an agent to decide when and how to use it. Output schema exists, so return values need not be described.

  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 coverage is 100% and the description adds no parameter-specific information beyond what the schema already provides. The baseline of 3 is appropriate since the schema fully documents the single 'query' parameter.

  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 'Performs a web search via Gemini + Google Search grounding', identifying the specific verb, resource, and mechanism. It also distinguishes itself from siblings by noting 'Independent of Tavily/Firecrawl', making its purpose unambiguous.

  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 'use as a second search path for cross-validation', providing a clear when-to-use context. It also names the alternatives (Tavily/Firecrawl) and mentions the prerequisite GEMINI_API_KEY, giving explicit guidance.

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

• get_config_infoA
  4.6/5.0
  Behavior5/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 discloses that API keys are automatically masked, connection test has a 10-second timeout, and it sends a request to the /models endpoint. These are valuable behavioral traits beyond the mere statement of function, making the tool's operation predictable and safe.

  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 well-structured with clear sections for Key Features and Edge Cases/Best Practices. Every sentence provides useful information, and the bullet points make it scannable. It is appropriately sized, not overly verbose, and front-loaded with the core purpose.

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

  Completeness4/5

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

  The tool has no output schema, so the description should explain return values. It mentions returning configuration, listing models, and testing connectivity, but does not specify the exact structure of the response. Given the simplicity of the tool and the richness of behavioral details provided, this is quite complete, though a brief mention of the response format would make it fully comprehensive.

  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 tool has zero parameters, so the input schema provides complete coverage. The description adds no parameter-specific information, but with no parameters, there is nothing to explain. The baseline for zero parameters is 4, which is appropriate here.

  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: 'Returns current multsearch MCP server configuration and tests API connectivity.' The verb 'returns' and 'tests' are specific, and the resource is well-defined. It also lists key features (configuration check, connection test, model discovery) which further clarifies the scope and distinguishes it from sibling tools like web_search or get_sources.

  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 provides explicit usage guidance: 'Use this tool first when debugging connection or configuration issues.' This gives a clear context for when to employ the tool, though it does not explicitly mention alternatives or exclusions. This is a clear context with no exclusions, qualifying for a 4.

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

• switch_modelA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It transparently reveals persistence to ~/.config/multsearch/config.json, immediate effect, and the risk of invalid model IDs causing API errors. It also notes that changes persist across sessions until explicitly changed, providing a complete behavioral picture.

  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 well-structured with clear sections for key features and edge cases. Every section provides meaningful information without fluff. The length is appropriate for the tool's complexity and the rich context it provides.

  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's simplicity (one parameter, no output schema, no annotations), the description fully covers purpose, usage, persistence, immediate effect, and edge cases. It equips the agent with all necessary context to select and invoke the tool correctly.

  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 schema already covers 100% of the parameter semantics with a clear description and example. The tool description adds value by warning about invalid model IDs and suggesting verification via get_config_info, which enriches the parameter's context beyond the 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 clearly states the tool's action: 'Switches the default LLM model used for search and fetch operations, persisting the setting.' This specific verb+resource combination distinguishes it from sibling tools like web_search and get_config_info, which serve different functions.

  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 advises using get_config_info to verify available models before switching, directly addressing when to use this tool versus an alternative. The 'Edge Cases & Best Practices' section further clarifies usage context and potential pitfalls.

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