Server Quality Checklist

Tool Scores

• list_modelsB
  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 must carry the full burden of behavioral disclosure. It only says 'list available AI models' without describing side effects (likely none), auth needs, rate limits, or the structure of returned data. It adds little beyond the tool's name, leaving the agent to guess about defaults and response format.

  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 a single concise sentence, one line long, with no filler. However, it includes the inaccurate 'capability' term, which slightly detracts from its precision, but overall it is appropriately brief.

  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?

  Without an output schema, the description should explain what the tool returns (e.g., model IDs, names, provider metadata). It doesn't. It also doesn't disclose default limit behavior or note the discrepancy around 'capability.' For a simple tool, it's under-specified regarding response structure and edge cases.

  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?

  Although the schema has full descriptions for both parameters (100% coverage), the description introduces 'filtering by provider or capability,' but there is no 'capability' parameter in the schema. This is misleading and adds confusion. It omits the limit parameter and doesn't clarify the filtering semantics 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 uses the specific verb 'list' with the resource 'available AI models' and mentions optional filtering. This clearly differentiates it from sibling tools get_ai_recommendation and get_code_template, which serve different purposes.

  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 clear context that this tool is for listing models and implies filtering options. It doesn't explicitly state when to avoid it or mention alternatives, but the sibling names make the use case obvious. There are no exclusions or prerequisites mentioned, which is acceptable for such a simple listing tool.

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

• get_code_templateA
  3.9/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 transparency burden. It discloses that the tool requires an API key (pro feature) and emphasizes template quality ('battle-tested', 'proper error handling'), but it does not specify what happens without an API key, response format, error behavior, or rate limits beyond the free-user note about recommendations, leaving gaps.

  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 two sentences and front-loads the core purpose. The second sentence adds quality and access context, though the free-user note about recommendations is somewhat tangential for a template tool. Still, each sentence 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?

  For a simple getter tool with two well-documented parameters and no output schema, the description covers the essential use case, language options, and access restriction. It does not describe return format or error handling, but the tool's simplicity and the presence of a sibling for listing models reduce the need for more detail.

  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% for both parameters ('model' and 'language'), so the schema already explains their meaning. The description mentions 'TypeScript & Python', matching the language enum, but adds no additional semantic detail 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 function: 'Get ArchitectGBT's production-tested code templates for AI model integration' with specific languages (TypeScript & Python). It uses a specific verb ('Get') and resource ('code templates'), and distinguishes itself from siblings like 'get_ai_recommendation' and 'list_models' by focusing on templates rather than recommendations or model lists.

  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 clear usage context by noting it's a 'Pro feature - requires API key' and mentions free-user limits, implying this tool is intended for paying users. It does not explicitly name alternatives or exclusion criteria, but the context makes it clear that this tool is for obtaining code templates, while siblings serve different purposes.

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

• get_ai_recommendationA
  4.5/5.0
  Behavior5/5

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

  No annotations are provided, so description carries full disclosure burden. It discloses a rate limit ('3 recommendations/day'), an authentication requirement ('Add ARCHITECTGBT_API_KEY'), and the nature of the output (pricing, reasoning, alternatives). This gives agents clear behavioral expectations.

  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?

  Description is front-loaded with purpose and scope, then adds necessary details in a compact, efficient manner. Every sentence provides meaningful information without redundancy.

  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 lacking annotations and output schema, the description covers the tool's purpose, scope, rate limits, auth, and output content. It is sufficiently complete for an AI agent to use the tool correctly, with schema covering parameter details.

  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%, so description does not need to explain parameters. It adds no extra meaning beyond the schema's existing descriptions of prompt, budget, and priority. Baseline 3 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?

  Description clearly states the tool provides AI model recommendations specifically for software projects, using a specific verb ('Get') and resource ('AI model recommendations'). The 'SOFTWARE PROJECTS ONLY' scope and exclusion of non-software tasks distinguishes it from sibling tools like get_code_template and list_models.

  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 explicit when-to-use (software projects) and when-not-to-use (physical projects, crafts, non-software) instructions. However, it does not name alternative tools or explain when to prefer siblings like list_models, so it lacks full alternative differentiation.

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