Server Quality Checklist

Tool Scores

• listSitesB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, and the description only says 'List Netlify sites' without disclosing any behavioral traits such as pagination, read-only guarantees, rate limits, or response format. The verb 'list' implies a read operation, but no explicit transparency is given.

  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 that directly states the purpose. It is appropriately short and front-loaded, with no filler, though it omits some contextual detail that could be valuable.

  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?

  With no output schema and minimal annotations, the description should explain return values or operational details. It doesn't mention the filter parameter, response shape, or any behavior beyond listing. For a simple tool it is workable, but it lacks completeness for an agent to fully understand invocation and 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 schema fully describes the only parameter 'filter' with its enum values and description, achieving 100% schema coverage. The description adds no additional parameter meaning, so the baseline score of 3 applies.

  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 'List Netlify sites' clearly states the action (list) and resource (Netlify sites). It distinguishes itself from siblings by indicating a plural list operation versus create/get/delete actions.

  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 like getSite or when not to use it. There is no mention of context or exclusions, leaving the agent to infer typical list usage.

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

• deleteSiteB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description must convey behavioral traits. 'Delete a site' implies destruction but does not disclose permanence, reverts, permissions, or effects on associated resources. This is a significant gap for a mutation tool.

  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?

  One short sentence, free of fluff. It is concise but borders on under-specification; however, for a simple delete operation, this length is appropriate.

  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 (1 param, no output schema), but with no annotations the description should note irreversibility or return value. It is minimally complete for a trivial delete op, but leaves gaps.

  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 the baseline is 3. The description adds no meaning beyond what the schema already provides for 'siteId', but the parameter is self-explanatory.

  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 verb 'delete' clearly states the action, and 'site' identifies the resource. This distinguishes it from siblings createSiteFromGitHub, listSites, and getSite. Minimal but unambiguous.

  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 on when to use this tool, prerequisites, or consequences. The description gives no context beyond the action itself, leaving the agent to infer usage solely from the name.

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

• createSiteFromGitHubA
  3.6/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 disclosing behavioral traits. It only states the action without mentioning side effects, permissions, idempotency, or potential error conditions. For a mutation tool like create, this is a notable 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 a single, succinct sentence that conveys the essential purpose without any fluff. It is appropriately sized and easy to scan.

  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?

  For a tool with 5 required parameters and no annotations or output schema, the description only explains the high-level purpose. It does not describe the return value, error handling, or any prerequisites, making it incomplete for a new agent to confidently invoke it 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 descriptions for all 5 parameters, with 100% coverage. The tool description adds no extra parameter semantics beyond what the schema already explains, so a baseline score of 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?

  The description states 'Create a new Netlify site from a GitHub repository' with a specific verb ('create'), a clear resource ('Netlify site'), and a source ('GitHub repository'). This clearly distinguishes it from the sibling tools listSites, getSite, and deleteSite, which perform other CRUD operations.

  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 creating a site from GitHub, and the sibling names make it obvious that it is the creation operation. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a full 5.

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

• getSiteA
  3.8/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It clearly indicates a read operation ('Get') with no side effects, but it does not disclose details such as return format, error behavior, or authentication requirements. The description adds minimal behavioral context beyond what the name itself implies.

  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 ('Get details of a specific site') that front-loads the verb and resource. Every word contributes to meaning, with no redundancy or unnecessary detail.

  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 is simple with one well-documented parameter and no output schema. The description is sufficient for a basic get operation, though it lacks explicit usage guidance and return value details. Given the low complexity, the description is nearly complete, with only minor gaps.

  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 documents the single parameter siteId with the description 'ID of the site to retrieve' (100% schema coverage). The tool description does not add any additional meaning about the parameter, so the baseline score of 3 applies.

  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 'Get details of a specific site' uses a clear verb ('Get') and resource ('site'), and the qualifier 'specific' distinguishes it from sibling tools like listSites, which retrieves multiple sites. It unambiguously states the tool's function.

  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 retrieving a single site's details by ID, but it does not explicitly state when to use this tool versus alternatives like listSites. No exclusions or alternative recommendations are provided, leaving usage context only implicit.

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