Server Quality Checklist

Tool Scores

• http_inspectA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the burden. It discloses a key behavioral trait (no HTTP call), but lacks details on cache miss handling, permissions, or idempotency.

  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?

  Two sentences with no fluff. First sentence states purpose and options, second provides usage guidance. Information is front-loaded and every word earns its place.

  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?

  Given the simple 2-param tool with no output schema, the description covers purpose, format options, and a behavioral trait. Missing context about cache_id source and error handling, but mostly 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%. The description adds context for schema_format with recommendations, but does not explain cache_id or how to obtain it. The enum values are listed in schema, so some value is added but incomplete.

  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 re-renders a cached response schema in different formats without a second HTTP call, using specific verbs and resource. It distinguishes from siblings like http_read and http_request by emphasizing cache inspection.

  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 gives recommendations on when to use each format (e.g., 'Try `shape` for nested structures'), but does not explicitly contrast with sibling tools or specify when not to use this tool.

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

• http_readA
  4.2/5.0
  Behavior4/5

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

  Discloses key behaviors: binaries are never inlined, save_to is required for binary bodies, mask works only on JSON. Since no annotations are provided, the description carries full burden and does a good job of conveying important behavioral details beyond schema.

  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?

  Three sentences: first states core purpose, second gives a usage tip, third clarifies binary handling. Every sentence adds value; no fluff or repetition. Front-loaded effectively.

  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?

  With 4 parameters, no output schema, and no annotations, the description sufficiently covers binary handling, mask scope, and caching context. Slightly lacking in explicitly stating it reads cached responses (implied), but otherwise complete for a read tool.

  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 high (75%). Description adds limited extra parameter meaning—mostly a tip for mask usage. Baseline of 3 is appropriate as schema already provides descriptions for mask, output_mode, and save_to. No mention of cache_id semantics beyond being required.

  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?

  Description clearly states 'Read a cached response body, optionally filtered through a jq mask.' It specifies the verb 'read' and resource 'cached response body', and distinguishes from siblings like http_request (which makes requests) and http_inspect (likely inspects metadata) by focusing on cached data retrieval.

  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?

  Provides actionable tips: leading with 'length' to learn size, requiring save_to for binary bodies, and noting mask validity only for JSON. Missing explicit when-not-to-use or alternatives to siblings, but the guidance is clear and context-aware.

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

• http_requestA
  4.7/5.0
  Behavior5/5

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

  No annotations provided, but the description fully covers behavior: returns schema and cache_id by default, body_mode controls body inclusion, multipart uses chunked encoding (may fail on legacy proxies). It does not contradict annotations (none provided).

  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?

  Well-structured and front-loaded with key information, but slightly lengthy. However, every sentence serves a purpose, and the cookbook adds practical value without being verbose.

  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?

  Given the tool's complexity (14 parameters, nested objects, no output schema), the description covers essential usage patterns, workflow, and caveats. Could mention error handling or authentication, but overall adequate.

  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 description coverage is 71%, so baseline is 3. The description adds significant value by explaining body_mode in detail and the overall request flow, going beyond schema descriptions.

  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 HTTP requests and returns a compact schema of the response, not the full body. It distinguishes itself from siblings http_read and http_inspect by explaining the two-step workflow.

  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?

  Explicitly describes the default two-step flow and provides a cookbook with specific examples. It also advises when to use body_mode options sparingly, especially inline mode, and notes multipart streaming constraints.

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

• server_infoA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses the tool's behavior: it is a read-only debug helper with no side effects, returning specific fields. It explains exactly what is returned and notes reference to README for full list, leaving no ambiguity.

  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 concise (5 sentences) and front-loaded with 'Debug helper. No params.' It efficiently communicates purpose, return values, and usage, with no wasted words.

  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 no parameters, no output schema, and low complexity, the description is complete. It lists all return fields and directs to README for the full effective_limits list, which is sufficient for an agent to understand 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?

  There are no parameters, and schema description coverage is 100%. The description adds no param details because none are needed, but the baseline score of 4 is appropriate for a zero-parameter tool.

  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 it is a 'debug helper' that returns server information such as version, runtime detection, cwd, files_root, and effective_limits. It distinguishes itself from sibling tools (http_inspect, http_read, http_request) which are HTTP-related, so the agent knows this is the only info/debug tool.

  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 scenarios: 'Use when a path is rejected unexpectedly, or to confirm which container/host the server is actually running in.' This gives clear context, though it doesn't mention when not to use the tool, which would be helpful but not essential.

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