Server Quality Checklist

Tool Scores

• ollama_pull_modelA
  4.7/5.0
  Behavior5/5

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

  Annotations indicate write, idempotent, non-destructive. Description adds file size range, idempotency verification, authentication, rate limits, execution time, error behavior. 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.

  Conciseness5/5

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

  Description is eight sentences, each adding value, with front-loaded purpose and clear structure. No redundancy or fluff.

  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?

  Covers usage, behavior, constraints, and error handling. Output schema exists, so return value details are not required. Comprehensive for a download 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?

  Schema coverage is 100% with detailed parameter description. The tool description does not add meaning beyond the schema, so 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 specifies downloading a model from the Ollama library to the local machine, using a clear verb and resource. It distinguishes from sibling tools by stating when not to use it (e.g., for inference or when model is already present).

  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 when to use (model needed but not installed) and when not to use (if already installed, use ollama_list_models first; for inference, use ollama_chat or ollama_generate). Provides clear alternatives.

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

• ollama_generateA
  4.8/5.0
  Behavior5/5

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

  Description states read-only, not idempotent (each call produces different output), no authentication, no rate limits, network-dependent, safe to retry on timeout, and error handling. This adds significant context beyond annotations (readOnlyHint: true, etc.) and 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.

  Conciseness4/5

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

  Description is a single paragraph but well-structured: starts with purpose, then use cases, prerequisites, behavioral details. Every sentence adds unique value. Slightly longer than minimal but no redundancy, 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?

  Given the tool's complexity (5 params), presence of output schema, and sibling tools, the description covers purpose, usage guidelines, prerequisites, behavior, and error handling. With output schema existing, it doesn't need to explain return values. Complete for selecting and invoking.

  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 description coverage is 100%, but the description adds valuable context: suggests calling ollama_list_models for model parameter, explains prompt length is context-window limited, maps max_tokens to Ollama 'num_predict', and gives usage tips for temperature. Goes beyond schema but is not essential since schema already covers basics.

  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 'Generate a single-turn text completion from an Ollama model without conversation history.' Uses specific verb and resource, lists use cases (code generation, etc.), and explicitly distinguishes from sibling ollama_chat (multi-turn).

  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 tells when to use (one-shot tasks) and when not to (multi-turn conversations), directing to ollama_chat. Also provides prerequisites: model must be installed, with instructions to verify via ollama_list_models and pull via ollama_pull_model.

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

• ollama_healthA
  4.8/5.0
  Behavior5/5

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

  Description adds behavioral traits beyond annotations: 'Read-only, idempotent, safe to retry. No authentication required. No rate limits. Makes a single HTTP GET... On connection failure returns an error object without throwing.' This provides rich context for safe usage.

  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?

  Four sentences with clear front-loading. Could be slightly trimmed but all information 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, rich annotations, and an output schema, the description fully covers usage context, behavior, and error handling. Nothing essential is missing.

  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, so baseline 4 applies. Description does not need to add param details as there are none.

  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 it checks Ollama daemon connectivity and lists running models. Explicitly distinguishes from ollama_list_models by specifying it does not list all installed models.

  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 recommends using this as the first call to verify service reachability before other tools. Also states to not use for listing all installed models, with alternative provided (ollama_list_models).

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

• ollama_chatA
  4.9/5.0
  Behavior5/5

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

  Beyond annotations (readOnly, non-idempotent, non-destructive), the description adds: 'Read-only (no state changes on the server)', 'not idempotent', 'No authentication required', 'No rate limits', 'Network-dependent; response time varies', 'Safe to retry on timeout', and error behavior. No contradiction 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.

  Conciseness5/5

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

  The description is concise and well-structured: purpose, usage, prerequisites, behavior notes. Each sentence serves a clear purpose, no redundant or filler content. Front-loaded with key information.

  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 tool's complexity (5 params, 2 required), high schema coverage, and existence of output schema, the description covers all essential aspects: purpose, usage context, prerequisites, behavioral quirks, and parameter hints. Return values are not needed due to output schema.

  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%, but the description adds contextual meaning: explains 'system' field as a shortcut with precedence, describes 'messages' array ordering, and gives temperature guidance (low for factual, high for creative). While schema already defines parameters, the description enriches operational 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 ('Send'), resource ('multi-turn chat completion request to an Ollama model'), and specifies the use case (conversational interactions with history). It explicitly differentiates from sibling tool 'ollama_generate' by advising against single-prompt usage, making the purpose distinct.

  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?

  Provides explicit when to use (multi-turn, follow-up, multi-step reasoning) and when not to use (single-prompt, use ollama_generate). Includes prerequisites: model must be installed, with references to ollama_list_models and ollama_pull_model. Also describes error behavior (returns error without throwing on model-not-found), guiding safe handling.

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

• ollama_list_modelsA
  4.9/5.0
  Behavior5/5

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

  Description adds context beyond annotations: 'No authentication required. No rate limits. Returns an empty models array if no models are installed.' This fully discloses behavior and aligns with annotations (readOnlyHint, idempotentHint).

  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 each serving a distinct purpose: function, usage guidance, and behavioral note. No redundant 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 list tool with good annotations and an output schema, the description covers all necessary aspects: purpose, when to use, behavior, and return states. Complete for agent decision-making.

  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?

  Tool has 0 parameters, baseline is 4. Description clarifies no input needed, and schema is empty. No further parameter detail required.

  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 verb 'List' and resource 'Ollama models installed on the local machine with their memory load status.' It distinguishes from sibling tools by specifying its role in discovering model names before using other tools.

  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 advises when to use (before ollama_chat, ollama_generate, etc.) and when not to use (for checking daemon status, recommends ollama_health instead). Also notes idempotency and safe retry.

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

• ollama_show_modelA
  4.9/5.0
  Behavior5/5

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

  Annotations already indicate read-only, idempotent, non-destructive. Description adds read-only, idempotent, safe to retry, no auth, no rate limits, consistent returns, and error handling behavior. 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.

  Conciseness5/5

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

  Concise, well-structured, front-loaded with purpose, bullet-like guidelines, every sentence adds value. No unnecessary 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?

  Covers purpose, usage, prerequisites, behavior, error handling. With good annotations and output schema, nothing missing. Complete for a simple inspection tool.

  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%, baseline 3. Description adds value by explaining the parameter is an exact identifier from ollama_list_models, provides examples, and suggests calling that tool first if unsure.

  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 it retrieves detailed metadata about a specific installed Ollama model, including architecture, license, etc. It clearly distinguishes from sibling tools like ollama_list_models and ollama_pull_model.

  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 when to use (before ollama_chat/generate), when not to use (listing or downloading models), prerequisites (model installed), and alternative tool names are provided.

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