Server Quality Checklist

Tool Scores

• delegate_listC
  2.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 full burden. It discloses ordering and grouping, but does not state whether the tool is read-only, has performance implications, or returns partial results. The lack of mutation or safety context is a gap.

  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 includes key details (ordering, grouping). No wasted words, though it could be slightly more informative without becoming verbose.

  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?

  The tool lists delegated jobs from a server's lifetime with no output schema. The description is sparse: it does not explain what fields are returned, pagination behavior, or how grouping works. More context is needed for an agent to use this tool effectively.

  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 coverage is 100% and the schema descriptions are clear for both parameters, so the baseline is 3. However, the description adds no extra meaning beyond what the schema already provides (e.g., does not explain what 'state' values mean in context, how limit interacts with grouping, or defaults).

  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 lists delegated jobs, specifying order (newest first) and grouping (by conversation). It distinguishes from siblings like delegate_status or delegate_result, but could be more explicit about what 'delegated jobs' refers to in context.

  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 versus siblings such as delegate_status or delegate_cancel. The description does not mention prerequisites, typical use cases, or when not to use it, leaving the agent to infer based on name alone.

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

• delegate_cancelA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does add one key behavioral trait: that cancellation terminates 'everything it started,' indicating cascading termination. However, it omits details like whether the operation is destructive (assumed but not stated), whether it requires any permissions, or what the return behavior is (e.g., blocking, asynchronous).

  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 sentence of 9 words, with the core verb 'Terminate' front-loaded. Every word adds value, and there is no fluff or redundancy. It is as concise as possible while still conveying the key behavioral nuance of cascade cancellation.

  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's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate. It specifies what it terminates and the scope, but does not cover important usage context such as error cases (e.g., cancelling a non-existent session), whether it is safe for any session, or what the result looks like. Some additional detail would improve completeness.

  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% description coverage for the single parameter 'job_id' with a clear description. The tool description adds no further semantic detail beyond what the schema already provides, so the 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 'terminate a running delegated Ollama session and everything it started,' which specifies the action (terminate), the resource (delegated Ollama session), and an important scope ('everything it started'). This distinguishes it from sibling tools like delegate_start and delegate_status.

  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 implicitly indicates use for canceling a running session but provides no explicit guidance on when to use versus alternatives (e.g., delegate_status to check status first) or when not to use (e.g., if the session is already completed). It lacks any before/after context or exclusion conditions.

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

• delegate_statusA
  4.1/5.0
  Behavior4/5

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

  Without annotations, the description carries the full burden. It transparently discloses the tool's behavior: it reports running status, provides a tail of activity (including tool calls and partial text), and can optionally block for a specified duration. It does not mention potential side effects, but since it's a read-only monitoring operation, the disclosure 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.

  Conciseness4/5

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

  The description is two sentences, front-loaded with the core purpose. The second sentence adds a usage tip, which is relevant but slightly redundant. Every sentence earns its place, and there is no fluff.

  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 there are 3 parameters, no output schema, and no annotations, the description is reasonably complete. It explains the tool's purpose, the key output (status and trace), and the optional blocking feature. It lacks explicit mention of the return format or error cases, but for a monitoring tool this is acceptable.

  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 each parameter has a description in the schema. The description adds no additional parameter semantics beyond the schema, so 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?

  The description clearly specifies the tool reports the status of a delegated job ('Report whether a delegated job is still running'), a tail of activity ('actual tool calls and partial text'), and the option to block until completion. This distinguishes it from siblings like delegate_start (which initiates a job) and delegate_result (which presumably gets the final result).

  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 gives explicit context for when to use this tool: to check if a delegate is still running and to use the tool-call trace to verify a delegate's actions. It does not explicitly state when not to use it or name alternatives, but the context ('Use the tool-call trace to check that a delegate really did the work it claims') implies it is for post-delegation monitoring versus delegate_cancel for aborting.

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

• delegate_startA
  4.3/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden. It discloses key behaviors: the tool runs in its own process with its own environment, so the user's Anthropic credentials and model settings are untouched. It also mentions that delegation mode is 'ondemand.' However, it does not detail what happens upon failure (e.g., if the Ollama model is unavailable) or the format of the returned job_id, leaving minor 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 structured with a clear first paragraph about the tool's function and a separate 'WHEN TO USE' section. It is front-loaded with the core purpose. However, the second paragraph could be slightly more concise—it repeats the 'ON EXPLICIT REQUEST ONLY' instruction—and the policy enforcement sentence adds redundancy. Still, it is efficient overall.

  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 an 11-parameter tool with no output schema, the description provides sufficient context: it explains the async nature, mentions sibling tools for follow-up, and includes usage boundaries. Some details about parameter interplay (e.g., wait_seconds vs. polling with delegate_status) or return value format are missing, but the description is functionally complete for selecting and invoking the tool.

  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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it mentions using `prompt_file` for long prompts and lists a few sibling tools for polling/collection. It does not elaborate on parameter constraints or relationships (e.g., mutual exclusivity of prompt and prompt_file).

  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: 'Start a headless Claude Code session backed by an Ollama model and return immediately with a job_id.' It identifies the resource (delegate session) and the action (start). It also distinguishes itself from siblings by mentioning polling with delegate_status, collecting with delegate_result, and continuing with delegate_followup, making differentiation clear.

  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?

  The description provides explicit when-to-use instructions: 'ON EXPLICIT REQUEST ONLY' and lists triggering phrases like 'delegate this', 'use ollama', 'ask qwen', etc. It also states when not to use: 'If the user has not asked for delegation, do the work yourself and do not offer this tool unprompted.' This is exemplary usage guidance.

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

• delegate_followupA
  4.4/5.0
  Behavior4/5

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

  The description explains that a new job_id is returned for this turn while the session_id remains the same, enabling back-and-forth interaction. Without annotations, the description carries the burden; it could mention any blocking behavior or side effects, but the transparency is strong.

  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 (three sentences), front-loaded with the core action, and every sentence adds value. No wasted 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?

  Given the 7 parameters, full schema coverage, no output schema, and no annotations, the description explains the essential behavior and identification methods. It could be more complete by noting the default behavior for optional parameters like max_turns or wait_seconds, but is largely sufficient.

  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 baseline is 3. The description mentions job_id and session_id as alternatives for identification but does not add new semantic meaning beyond the schema for other parameters. It doesn't go beyond what the schema already provides.

  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 sends another message to an existing delegated session, resuming conversation history. It distinguishes itself from siblings like delegate_start by focusing on continuation, and the title reinforces the purpose.

  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?

  The description explicitly states when to use this tool (continue a delegated conversation) and includes exclusion guidance: 'Only continue conversations the user asked you to start.' This clearly differentiates from delegate_start and sets a boundary.

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

• delegate_resultA
  4.4/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool blocks if wait_seconds is provided, and returns both the text and session_id. It does not discuss potential side effects, rate limits, or what happens if the job fails, but the blocking behavior is the key transparent element.

  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 two sentences long, front-loaded with the primary purpose, and every sentence adds value. There is no wasted text.

  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 only two parameters, no output schema, and no nested objects, so its simplicity reduces the required completeness. The description adequately covers the inputs and the blocking behavior. It could mention what happens if the job hasn't started yet or if it fails, but given the low complexity, this is sufficient.

  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%, so baseline is 3. The description adds meaning by explaining that 'job_id' is the collected delegation identifier and that 'wait_seconds' controls blocking up to a maximum. This clarifies the semantics beyond the schema's minimal descriptions.

  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 a specific verb ('Return') and resource ('final text...plus session_id'), clarifying the precise output. It distinguishes itself from sibling tools like 'delegate_status' (which likely returns status only) and 'delegate_start' (which starts work).

  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 (after a delegation is created, to get final output) and mentions the optional wait_seconds for blocking behavior. However, it does not explicitly contrast with 'delegate_followup' or 'delegate_status'—though the context signals suggest those exist.

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

• ollama_modelsA
  4.6/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It clearly states that the tool lists models, delegation mode, policy, and env vars, and that settings are user-controlled. It also warns that there is no tool to change them and instructs the agent not to edit config files. This covers the read-only nature and constraints. However, it does not mention any potential side effects, error conditions, or details about the output format, which would have made it a 5.

  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 four sentences, tightly packed with information. The first sentence gives the purpose, the second gives usage guidance, and the last two provide behavioral context and alternative actions. No redundant sentences or filler. It is well-structured and front-loaded, making it easy for an AI agent to parse quickly.

  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 the tool has no parameters, no output schema, and no annotations, the description provides a solid overview of what the tool returns and how to use it. However, it lacks a brief description of the output format (e.g., whether it returns a list of model names or a structured JSON). This is a minor gap, but overall the description is sufficient for the agent to understand the tool's purpose and constraints.

  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% (no parameters to describe). According to the guidelines, this gives a baseline of 4. The description does not add parameter semantics because there are none, and it correctly avoids adding unnecessary info. The score 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 starts with a specific verb 'List' and clearly identifies the resources: Ollama models, delegation mode, allowed-model policy, and environment variables. It distinguishes from sibling tools which are about delegation actions (start, cancel, followup, etc.) by focusing on listing models and configuration. This leaves no ambiguity about what the tool does.

  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?

  The description explicitly states when to use the tool: 'Use this to pick a model, or to report the current configuration when the user asks about it.' It also provides crucial guidance on what not to do: there is no tool to change settings, and the agent should tell the user to run 'ollama-mcp-config' in a terminal and restart the session, and not to edit config files. This is exceptional for an AI agent.

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