Server Quality Checklist

Tool Scores

• publish_siteA
  3.9/5.0
  Behavior4/5

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

  Annotations set destructiveHint: true and idempotentHint: true. The description adds behavioral details by explaining the first publish sets up external infrastructure (GitHub, Vercel) and subsequent calls are rebuilds, adding context beyond the annotations. However, it doesn't elaborate on what destruction entails.

  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, no redundancy, directly front-loads the core purpose. Every clause adds value, 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.

  Completeness5/5

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

  Given the simple single parameter, no output schema, and annotations covering key hints, the description adequately covers behavioral nuances (first vs subsequent call behavior) and external dependencies, completing the context.

  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 sole parameter siteId has a schema description indicating its source ('from list_user_sites or get_generation_status'), providing full schema coverage. The tool description does not add further parameter meaning, so baseline 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 clearly states the tool's action: 'Publish a site to production at slug.the-template-vault.com.' It distinguishes between first publish (wires up GitHub repo + Vercel project) and subsequent calls (triggers Vercel rebuild), differentiating from siblings like generate_site and get_generation_status.

  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 implies when to use the tool (to publish a site) but provides no explicit guidance on prerequisites, such as requiring a generated site first, or when not to use it. It does not mention alternatives like generate_site vs publish_site.

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

• list_personalitiesA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint. Description adds minimal behavioral context beyond listing styles, no mention of output format.

  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 concise sentences, front-loaded with action and resource, 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?

  For a simple listing tool with no parameters and no output schema, the description covers necessary info and usage context.

  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?

  No parameters; schema coverage is 100%. Description adds no param info, which 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?

  Clearly states 'List the visual personalities (styles)' with specific verb and resource. Distinguishes from siblings by linking to generate_site.

  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?

  Explicitly says 'Use to pick a style that fits the business before calling generate_site', providing clear context and prerequisite guidance.

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

• list_user_sitesA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint. The description adds no new behavioral traits beyond what annotations provide, but it does not contradict them.

  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, no fluff. The first sentence states purpose, the second provides a usage hint. Highly efficient and front-loaded.

  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?

  Complete for a parameterless tool with no output schema. The description covers purpose and a key usage scenario, leaving no gaps.

  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?

  No parameters exist, and schema coverage is 100%. The description correctly requires no parameter explanation, earning the baseline of 4.

  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 'List sites owned by the authenticated user', specifying the verb and resource. It also distinguishes this tool from siblings by linking its use to obtaining a siteId for publish_site.

  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?

  Explicitly says 'Use to find a siteId before calling publish_site', providing a clear use case. However, it does not mention when not to use or compare to other listing tools.

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

• get_generation_statusA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate readOnly and idempotent. Description adds context: return fields, timing expectations, and polling behavior, which goes beyond annotations and helps the agent understand usage.

  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 concise sentences: purpose, return fields, timing. No redundant information; front-loaded with key action and result.

  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 output schema, the description covers all relevant return fields and timing. For a simple polling tool with one parameter and no nested objects, it is complete.

  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% with a clear description for jobId. The description adds value by linking jobId to the output of sibling tool 'generate_site', improving semantic understanding.

  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 verb 'Check' and resource 'status of a generation job', listing specific return fields (status, siteId, progressPercent). It is distinct from sibling 'generate_site' which creates the job.

  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 polling guidance: recommended interval of 5 seconds and typical job duration of 30-90 seconds. Does not explicitly mention when not to use, but the purpose is well-scoped.

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

• discover_business_needsA
  4.6/5.0
  Behavior4/5

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

  Annotations already indicate readOnly and idempotent. The description adds behavioral context: the tool returns a question script, must be called first, and the user must ask questions sequentially. No contradictions with annotations.

  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?

  Description is front-loaded with 'REQUIRED FIRST STEP' and uses formatting for emphasis. Every sentence adds value, though slightly lengthy. Could be tightened slightly but remains effective.

  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 simplicity (1 optional param, no output schema), the description is complete. It explains the purpose, usage sequence, behavioral guidelines, and consequences of skipping. No gaps.

  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% and describes the optional businessHint parameter. The description adds meaning by explaining that the hint lets the tool tailor follow-up questions to the niche, beyond the schema's description.

  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 returns a question script and is the required first step before calling generate_site. It specifies the verb (returns), resource (question script), and context (business needs discovery). It distinguishes from siblings by mandating this tool before generate_site.

  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 says 'REQUIRED FIRST STEP' and 'ALWAYS call this tool first when a user asks to build/generate a website.' It provides when-not to skip: 'Skipping discovery produces minimal text-only sites.' Also instructs to ask questions one at a time.

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

• generate_siteA
  4.9/5.0
  Behavior5/5

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

  Discloses async execution (~30-90s), quota consumption, and content policy rejections. Annotations indicate destructiveHint=true and readOnlyHint=false; description aligns with and adds detail about the destructive creation process. No contradiction.

  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 long but well-structured with sections (prerequisite, content policy). Information is front-loaded, but some redundancy exists (e.g., mentioning async twice). Still efficient for the complexity.

  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 complexity (7 parameters, nested object, async, prerequisites, content policy, quota), the description covers all necessary aspects: return value, polling, prerequisites, edge cases, and restrictions. No output schema, but the polling mechanism is explained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions. The tool description adds extra context: businessProfile is emphasized as required for good results, skippedDiscovery only when user refuses, and specific advice for businessDescription and personality. This significantly enhances understanding.

  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: generating a new website. It specifies the async nature and return of a jobId. It distinguishes itself from sibling tools like discover_business_needs and get_generation_status by explaining prerequisites and subsequent polling.

  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?

  Explicit prerequisites are given: must call discover_business_needs first. Provides guidance on when to use skippedDiscovery if user refuses. Mentions content policy restrictions. Clearly sets context for tool usage.

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