Server Quality Checklist

Tool Scores

• get_tech_stackB
  3.3/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 full responsibility for behavioral disclosure. It merely states the purpose and does not mention return format, filters, read-only nature, authentication, or any other behavior. This is a significant gap for a tool without annotations.

  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 concise sentence that conveys the tool's purpose without any waste. It is front-loaded and efficient, achieving maximum clarity with minimal text.

  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 with one optional parameter and no output schema. The description tells what it does but does not specify the return format or the optional 'type' filter, which is only in the schema. It is minimally adequate but lacks richer context that an output schema or extra detail would provide.

  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 provides 100% coverage for the single optional parameter 'type', with a clear example. The description adds no additional meaning beyond the schema, so the baseline of 3 applies. The parameter is self-explanatory and the schema description is sufficient.

  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 retrieves detailed information about Srikanth's technical skills and tools. The verb 'Get' and the resource 'technical skills and tools' are specific, and it is clearly distinct from sibling tools focused on portfolio and contact info.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. The agent must infer that this tool is for tech stack inquiries based on the name and siblings.

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

• search_portfolioB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the search action, offering no information about match behavior (e.g., partial vs exact), case sensitivity, output format, or ordering. This is insufficient for an agent to predict tool behavior.

  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, focused sentence that directly states the core function. It avoids any filler or repetition, making it easy to parse quickly.

  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?

  While the schema is detailed, the description lacks crucial context such as what specific data is searchable, what 'content' means, and what the response format will be. The presence of sibling tools helps infer the overall domain, but the description alone does not fully prepare an agent to invoke the tool correctly.

  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 input schema provides complete descriptions for all three parameters, so the description adds minimal extra meaning. It does map 'keywords, category, or content' to query and category, which provides a slight semantic bridge. The limit parameter is self-explanatory from its schema default.

  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 with a specific verb ('Search') and resource ('Srikanth's portfolio data'), plus the search dimensions ('keywords, category, or content'). This distinguishes it from sibling tools like get_portfolio_item or get_portfolio_categories, which imply direct retrieval rather than search.

  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 for searching when the exact item is unknown, but it does not explicitly contrast with sibling tools. There are no when-to-use or when-not-to-use guidelines provided, so the agent must infer from the tool name and context that this is for broad searches, not specific lookups.

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

• get_contact_infoA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of disclosing behavior, but it mostly restates the tool's name. It does not specify whether it is read-only beyond the verb 'Get', what exactly 'all contact information' includes, or how results are returned.

  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, focused sentence with no filler or redundancy. It front-loads the action and resource effectively.

  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 description is minimally adequate for a simple zero-parameter getter, but it omits details such as output format, usage scenarios, and any limitations. Given no annotations or output schema, more context would help the agent understand exactly what to expect.

  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, so the input schema carries no burden and the baseline for zero-parameter tools is 4. The description's phrase 'all contact information' adds some informational context but there is no parameter to elaborate on.

  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 the specific action 'Get' and the resource 'all contact information for Srikanth', clearly distinguishing it from the portfolio-related sibling tools. It is unambiguous about what the tool returns.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives. There is no mention of context, prerequisites, or any exclusion such as 'use this only when you need contact details'.

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

• get_portfolio_itemA
  3.5/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 full responsibility for disclosing behavior. It only states that the tool gets an item by ID, with no mention of return format, error handling, rate limits, permissions, or whether the operation is read-only (though 'Get' implies it). The description adds minimal behavioral context beyond the tool's 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. Every word contributes meaning, making it highly concise and well-structured.

  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?

  For a simple getter with one well-documented parameter, the description provides enough to invoke the tool correctly. However, with no output schema, the description does not explain what a portfolio item contains or what the response looks like, and it omits error behavior. It is minimally complete but leaves gaps in expected output.

  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 input schema fully describes the 'id' parameter (type number, description 'The ID of the portfolio item to retrieve'), so schema coverage is 100%. The description adds nothing beyond 'by ID', which does not enhance the parameter's meaning. Baseline 3 is appropriate since the schema carries the semantic load.

  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 'Get a specific portfolio item by ID' with a specific verb and resource, and the 'by ID' qualifier distinguishes it from sibling tools like search_portfolio, which implies finding items without an ID. This is precise and unambiguous.

  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 when you have a known portfolio item ID, but it does not explicitly state when to use this tool versus alternatives like search_portfolio. There is no mention of prerequisites, exclusions, or comparison to sibling tools, so the guidance is left to inference.

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

• get_portfolio_categoriesA
  4.1/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 clearly indicates a read operation via 'Get', but adds no further context such as return format, ordering, or side effects. This is adequate but not rich, matching a minimal viable score.

  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, front-loaded sentence with no unnecessary words. It is concise and to the point, earning a 5.

  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 low complexity (no parameters, no output schema), the description fully captures its purpose and behavior. It is complete for a simple list-returning tool and does not require additional explanation.

  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 input schema has zero parameters, so schema coverage is 100% by vacuity. The description adds no parameter-level detail, but none is needed. With 0 params, the baseline of 4 is appropriate.

  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 the specific verb 'Get' with the resource 'all available categories in the portfolio data', clearly stating the tool's function. This distinguishes it from siblings like get_portfolio_item or get_tech_stack, which target different resources.

  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—when you need all categories—but does not explicitly discuss alternatives or when not to use it. Given the sibling tools, there is no clear comparison guidance, but the intent is understandable.

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