Server Quality Checklist

Tool Scores

• inkcheck_workflowC
  2.8/5.0
  Behavior1/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 does not disclose any behavioral traits such as mutability, idempotency, side effects, or error behavior, leaving the agent uninformed about consequences.

  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 with two front-loaded sentences. Every word adds value, no redundancy. It efficiently communicates the core purpose and a key usage instruction.

  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?

  Given the complexity of 13 enumerated operations and a nested request object, plus no output schema or annotations, the description is inadequate. It fails to explain return values, operation semantics, or error scenarios, leaving significant gaps for the agent.

  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?

  Schema description coverage is 50%, requiring compensation. The description merely reiterates 'pass the exact operation and request object' without adding meaning beyond the schema. It does not explain the purpose or constraints of the request object or operation enum values.

  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?

  The description clearly states the tool runs 'one post-discovery Inkcheck operation', providing a specific verb and resource. However, it does not explicitly distinguish from sibling tools like compile_story or inspect_story, though the unique operation set implies differentiation.

  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 instructs to call 'inkcheck_capabilities first for required/optional fields', which is a clear prerequisite. But it provides no when-to-use guidance, exclusions, or alternatives among sibling tools.

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

• start_searchB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description must fully disclose behavioral traits. It states the return value (opaque bearer capability, bounded findings, checkpoint) and synchronous nature, but omits side effects, permissions, error conditions, or state changes. More detail is needed for safe invocation.

  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 with two sentences, front-loaded with the core action and return values. Every sentence adds value without redundancy.

  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?

  With 8 parameters and no output schema, the description gives a high-level overview but lacks detail on return value structure, prerequisites (e.g., valid file), and workflow (e.g., how to use the returned capability). It is adequate but not complete.

  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%, so the description adds no additional parameter meaning. Per guidelines, baseline is 3. The description does not explain parameter interplay or usage beyond what the schema already provides.

  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?

  The description states a specific verb ('Start') and resource ('one durable exact shared-search result window'), distinguishing it from sibling tools that focus on compilation, capabilities, workflow, and inspection. The term 'shared-search' adds specificity but could be clearer.

  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 use for searching, but offers no explicit guidance on when to use this tool vs alternatives. It mentions synchronous execution but does not compare with sibling tools. The context is moderately clear for an agent to infer usage.

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

• compile_storyA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It discloses output format (structured issues with file/line numbers) but omits potential side effects, permission requirements, or error handling. Adequate but not comprehensive.

  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 deliver purpose and usage concisely. No filler; each sentence adds critical information.

  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?

  Covers core purpose and usage. Lacks detail on output structure and parameter effects on results, but sufficient for a compile tool with clear return type.

  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 baseline 3 applies. Description adds no extra meaning beyond schema for file, detail, or findingLimit parameters.

  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 it compiles .ink files with inklecate and returns structured issues. Distinguishes from siblings by calling itself 'authoritative syntax/structure check', differentiating from inspection or workflow tools.

  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 advises running after any .ink file edit, giving clear when-to-use context. Does not exclude alternatives or mention sibling tools, but usage direction is strong.

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

• inkcheck_capabilitiesA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It implies a safe read operation but does not explicitly state non-destructiveness or other behavioral traits like rate limits or idempotency. The description is minimal but adequate for a simple introspection 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?

  Two sentences with no wasted words. The key action and usage advice are front-loaded. Every sentence earns its place.

  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 zero parameters, no output schema, and a simple purpose, the description fully covers what the tool returns and when to use it. No gaps remain for an agent to understand its role.

  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 tool has zero parameters and schema description coverage is 100% (empty schema). Per guidelines, baseline is 4. The description does not need to add parameter info since none exist.

  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 the tool returns 'Inkcheck's versioned schemas, limits, search modes, and explicit supported/unsupported feature flags'. The verb 'Return' and specific resource are precise. It effectively distinguishes from sibling tools which focus on story 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?

  Explicitly advises 'Call this before relying on optional functionality', providing clear context for when to use. However, it does not mention when not to use or list alternatives explicitly.

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

• inspect_storyA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It discloses that the tool is read-only ('without compiling or exploring') and lists the returned fields. It does not cover permissions or rate limits, but for a read-only inspection tool, the transparency is adequate.

  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: two sentences. The first clearly states the action and caveats, the second lists the return fields. No unnecessary words, and key info is front-loaded.

  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?

  Considering the tool has 4 parameters with full schema descriptions, no output schema, and no annotations, the description explains the return value comprehensively (listing 7 components) and how to get an overview vs. drill-down. It is largely complete for the tool's purpose.

  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% (all 4 parameters have descriptions), so baseline is 3. The description adds value by relating the 'section' parameter to 'bounded overview', and implies that omitting section gives an overview. This extra context elevates the score.

  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 'inspect' and clearly identifies the resource as an 'Ink project from source'. It distinguishes itself from siblings like compile_story by explicitly stating 'without compiling or exploring it', making the purpose unambiguous.

  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 implies when to use this tool (for inspection before compiling/exploring) and mentions 'recommended next operation', but does not explicitly contrast with each sibling or state when not to use it. The guidance is clear but not exhaustive.

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