Server Quality Checklist

Tool Scores

• save_slice_dataB
  3.2/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. States it performs 'local changes' and returns success/errors, but lacks details on overwrite behavior, permissions, or reversibility. Minimal disclosure.

  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?

  Three sentences, no fluff. Front-loaded with purpose. 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?

  Adequately covers purpose and returns, but could be more explicit about the requirement that at least one of model/mocks must be provided (schema notes it, description does not). No output schema, but return description suffices.

  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% with well-described parameters. Description adds 'with given valid data' but little extra beyond schema. Baseline score appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states the verb 'creates or updates' and resource 'Prismic slice model and/or mocks' with scope 'local changes to the slice library'. Does not explicitly differentiate from sibling tools like add_slice_to_custom_type, but purpose is well-defined.

  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?

  Provides basic usage guidance: 'Use to validate and create/update slice data'. Does not mention when not to use or alternatives among siblings, but implication is clear.

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

• add_slice_to_custom_typeA
  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 must fully disclose behavior. It states it 'adds/registers/attaches' and 'regenerates types', but lacks details on side effects (e.g., overwrites existing registrations), required permissions, or the validation process. The warning about manual editing is helpful, but overall transparency is minimal 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.

  Conciseness5/5

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

  The description is concise (3 lines) and well-structured with 'PURPOSE', 'USAGE', and 'RETURNS' sections. Every sentence adds value; no fluff or repetition. Ideal for quick comprehension.

  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 covers purpose, usage, and return values (message/errors). However, it omits prerequisites (e.g., slice and custom type directories must exist, valid model.json) and does not explain the 'regenerates types' effect. For a tool with 3 required params and no output schema, it is adequate but leaves some 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 description coverage is 100% (all 3 parameters have clear descriptions). The description adds no extra detail beyond the schema, so baseline 3 is appropriate. The parameters are self-explanatory from the schema alone.

  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 explicitly states 'Adds a slice to a custom type'—a specific verb and resource. It also adds 'regenerates types' to clarify scope. This is direct and unambiguous, distinguishing it from sibling tools which focus on coding, mocking, or modeling slices.

  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 provides a 'USAGE' section stating it is the 'Required path for modifying Prismic slice registrations' and warns against manual editing. However, it does not explicitly compare to siblings or state when not to use it (e.g., when just modeling a slice). The guidance is present but not comprehensive.

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

• how_to_mock_sliceA
  3.6/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 disclose behavior. It states it 'generate[s]' a mock and 'provide[s] guidance,' but it doesn't clarify if this is a read-only operation or if it modifies files. It also doesn't mention permissions or side effects. It's adequate but lacks depth.

  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 concise with three clear sections: PURPOSE, USAGE, RETURNS. Every sentence adds value without repetition. It is front-loaded with the purpose. Slightly more detail could be added without being verbose, so not a perfect 5.

  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?

  Given the tool has 3 parameters, no output schema, and no annotations, the description covers the basic purpose but lacks completeness. It doesn't clarify whether the tool reads/writes files, the format of the returned JSON, or how it relates to sibling tools. More detail would be needed for full 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 input schema has 100% coverage with clear descriptions for each parameter (e.g., absolute paths, user intent). The tool description does not add extra meaning beyond what the schema already provides, but the schema itself is sufficient. Following the baseline rule for high coverage, a 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 clearly states the tool's purpose: 'Generate a model-valid slice mock (mocks.json) and provide guidance for text-only refinements.' The verb 'generate' and resource 'slice mock' are specific. The sibling tools include other how-to tools (code, model), so this tool is distinct as the mocking one.

  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 says 'Use when creating or updating slice mocks.' This gives a clear context but does not explicitly mention when not to use it or provide alternative sibling tools. No exclusions or comparisons are given, so it's implied but not fully guided.

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

• how_to_code_sliceA
  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 carries the full burden. It states the tool 'Provides slice and field implementation guidance' and 'RETURNS: ... documentation and code examples', implying a read-only knowledge retrieval. However, it does not explicitly confirm non-destructive behavior or disclose any side effects, which is minimal but acceptable for a guidance tool.

  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 extremely concise: three sentences with clear labels (PURPOSE, USAGE, RETURNS). Every sentence adds value, and the structure is front-loaded. No unnecessary words.

  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 has 5 required parameters and no output schema. The description summarizes the return value as 'Prismic Framework-specific field documentation and code examples', which is somewhat general but sufficient for a guidance tool. It could mention output format or error handling, but overall it covers the essential 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?

  Schema description coverage is 100%, providing clear descriptions for all 5 parameters. The tool description does not add extra meaning beyond what the schema already conveys, so the 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 explicitly states it provides slice and field implementation guidance for Prismic slice components, which is a specific verb+resource. It clearly differentiates from sibling tools like 'how_to_mock_slice' (mocking) and 'how_to_model_slice' (modeling).

  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 says 'Use FIRST when working with any Prismic slice component or field implementation', providing clear context and priority among siblings. It does not explicitly list when not to use or alternatives, but the instruction is direct and helpful.

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

• how_to_model_sliceA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It clearly states it returns step-by-step guidance, naming conventions, shapes, etc. It does not mention side effects, but as a guidance-only tool, that's acceptable. Could be more explicit about not making changes.

  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 with sections (PURPOSE, USAGE, Input Type Selection Rules, RETURNS) and bold headings. Concise but informative; each sentence adds value. Could be slightly more streamlined.

  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 no output schema, the description covers purpose, usage, parameter guidance, and return value. It's adequate for an AI agent to select and invoke correctly. Missing only explicit mention that it does not modify anything, but implied.

  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 good descriptions. The description adds extra meaning: explains input type selection rules, gives an example for contentRequirements, and reinforces the PascalCase pattern for sliceName. This adds significant value beyond 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 purpose: providing opinionated guidance for Prismic slice model files. It specifies the resource (slice model files) and action (create or update), and distinguishes from sibling tools like how_to_code_slice and how_to_mock_slice.

  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 states 'Use FIRST for any Prismic slice creation or modeling request' and 'Do not use for component or mock implementation.' Provides detailed input type selection rules, giving clear context on when to include each input type.

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