Server Quality Checklist

Tool Scores

• ollama_pull_modelA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only says 'Download and install,' which essentially restates the tool's name. It does not disclose potential side effects like large downloads, time requirements, network dependence, or idempotency.

  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, focused sentence with no wasted words. It conveys the core purpose efficiently.

  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?

  For a simple one-parameter tool, the description is minimally adequate but lacks important context such as network requirements, storage considerations, and return behavior. Since no annotations or output schema exist, this is a clear gap preventing a higher score.

  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 a clear parameter description and examples. The description adds no extra meaning beyond what the schema already provides, 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 states the action ('Download and install') and the target resource ('a new model to Ollama'), using a specific verb and distinguishing it from siblings like ollama_generate_text or ollama_list_models.

  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 context is clear (needed when a new model is required), but no explicit alternatives or exclusions are provided. The tool does not mention when NOT to use it or point to related tools like 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_list_modelsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It states the operation is a 'List' of models and clarifies 'local system', implying a read-only action, but it does not add additional behavioral context such as return format, potential network calls, or side effects. For a simple list operation, this is adequate but not rich.

  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 that is concise, front-loaded with the action ('List'), and contains no superfluous information. It is highly efficient and easy to parse.

  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 a simple list tool with no parameters and no output schema, the description covers the core purpose and scope ('all available models on the local system'). It is complete enough for an agent to understand what the tool does, though it does not explicitly state the return format, which is implied by 'List'. Given the simplicity, this is reasonable completeness.

  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 the input schema is an empty object with 100% schema coverage. Since there are no parameters to explain, the description adds no parameter semantics, but the baseline for 0 parameters is 4, and the description does not need to compensate for any missing parameter information.

  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 'List' and the resource 'all available Ollama models on the local system', which precisely defines the tool's function. It distinguishes itself from sibling tools (like ollama_generate_text or ollama_pull_model) by specifying it lists models rather than performing generation or pulling.

  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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention scenarios like 'Use this before generating to see available models' or any exclusions. The only implication is via the verb 'List', but no concrete usage context is provided.

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

• ollama_summariseA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It adds useful capability boundaries (not for interpretation/analytical) and mentions token-saving for batch tasks, but it does not disclose return format, whether an external model call is made, or any other side effects/limitations.

  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 compact, front-loaded with the primary action, and every sentence adds distinct value: purpose, use cases, batch/token-saving benefit, and an explicit avoidance warning. No wasteful filler.

  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 is adequate for a simple summarization tool, covering purpose, usage, and restrictions. However, it omits model parameter semantics and return/output behavior, which is notable given there is no output schema and no annotations to fill those gaps.

  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 covers text and length descriptions, but the 'model' parameter has no schema description and is not mentioned in the tool description. The description's 'BRIEF' emphasis may conflict with the length parameter's default 'medium,' and no guidance is given for choosing among model or length values.

  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 opens with 'Create BRIEF summaries for logs, documentation, or simple content,' which clearly states the verb, resource, and scope. It also distinguishes itself from siblings like ollama_generate_text and ollama_chat by emphasizing 'factual condensation' and 'routine document processing.'

  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?

  It explicitly says 'Use for factual condensation and routine document processing' and 'AVOID for content requiring interpretation or analytical summarization.' This provides clear when-to-use and when-not-to-use guidance, though it does not name a specific alternative sibling tool for the analytical cases.

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

• ollama_code_generationA
  4/5.0
  Behavior3/5

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

  No annotations are present, so the description carries full responsibility for behavioral disclosure. It discloses a capability boundary (only simple/mechanical code) and defines scope, but does not describe return format, error behavior, or other runtime characteristics beyond that boundary.

  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 sentences, front-loaded with action and examples. Every sentence provides distinct value, and the AVOID clause is a compact clear exclusion.

  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 a simple, low-complexity tool with no output schema, the description provides adequate context about scope and boundaries. It lacks explicit output return details but the examples and use cases make the intended result obvious.

  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 covers 3 of 4 params (task, model, language), and temperature lacks a description. The description does not elaborate on parameter semantics beyond the schema, so it neither adds nor detracts; baseline 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 opens with 'Generate SIMPLE code' and lists concrete examples (getters/setters, CRUD, validation, boilerplate), making the tool's purpose unmistakable. The 'mechanical coding tasks' phrasing differentiates it from sibling text generation and chat 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?

  It explicitly states 'Use for mechanical coding tasks that follow established patterns' and 'AVOID for architectural decisions, complex business logic...' providing clear when/when-not guidance. However, it does not name a specific alternative sibling to route complex code requests to.

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

• ollama_embed_textA
  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 burden. It discloses that the tool uses local models and saves Claude tokens, which are useful behavioral traits. However, it does not mention prerequisites like model availability, return format, or rate limits. This is moderate disclosure, neither bare nor 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?

  The description is three sentences, each providing distinct value: what it does, use cases, and when to use it. It is concise, front-loaded with the primary action, and avoids redundancy.

  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 a simple two-parameter tool with no output schema, the description covers the purpose, use cases, and a benefit. It implicitly conveys the return type (embeddings) through the name and context. Minor gap: no mention of model management prerequisites, but sibling tools like ollama_list_models and ollama_pull_model suggest that.

  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 both 'text' and 'model' parameters clearly described in the schema. The description adds no additional parameter details beyond mentioning the default model in an example, which the schema already covers. 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 states the tool's function: generate text embeddings using local models. It distinguishes from siblings like ollama_generate_text and ollama_chat by specifying embedding generation and provides concrete use cases (semantic search, similarity, clustering).

  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 on when to use the tool: ideal for batch embedding tasks, semantic search, similarity comparisons, and clustering, and for routine embedding generation to save tokens. It lacks explicit alternatives or exclusions, but the usage context is clear and helpful.

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

• ollama_generate_textA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It discloses that the tool runs locally, is token-efficient, and is not suited for complex reasoning. However, it lacks details on execution behavior such as streaming, latency, error handling, or output format, which would be valuable for an agent.

  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 only two sentences, front-loaded with the primary purpose, and each sentence delivers distinct, useful information without redundancy. It is appropriately sized and easy to parse.

  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 a simple generation tool with no output schema or annotations, the description covers the core purpose, use cases, and limitations. It could mention the expected return value or explicitly differentiate from ollama_chat, but overall it provides sufficient context for an agent to decide when and how to invoke it.

  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 provides 100% coverage with descriptions for all four parameters (prompt, model, max_tokens, temperature). The description adds no parameter-specific meaning beyond what the schema already offers, 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 clearly states the tool generates text using local Ollama, specifies the scope (SIMPLE, token-efficient tasks) and provides concrete examples (basic content, error messages, placeholder text, boilerplate code, routine documentation). This specificity differentiates it from broader generation tools and implies its place among the sibling 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?

  Provides explicit when-to-use guidance ('Use instead of Claude for non-analytical text generation') and strong when-not-to-use guidance ('AVOID for complex reasoning, analysis, or creative writing...'). However, it does not explicitly reference sibling tools like ollama_chat or ollama_code_generation as alternatives, leaving some ambiguity within the Ollama tool family.

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

• ollama_chatA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the tool is intended for simple tasks and explicitly warns against complex reasoning, which is a key behavioral limitation. It also mentions the token-saving rationale. However, it doesn't describe output format or error behavior, which would enhance transparency further.

  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 composed of two sentences, front-loading the primary purpose and then providing usage guidance. It is concise and every sentence earns its place, though the use of ALL CAPS for emphasis is slightly distracting but does not harm clarity.

  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 no output schema and no annotations, so the description must provide context. It sufficiently covers purpose, usage boundaries, and the reason for preferring this tool. It doesn't explicitly mention prerequisites like local Ollama being installed or running, but the name and description imply this. Overall, adequate for a chat 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 description does not mention any parameters, leaving parameter semantics entirely to the schema. Schema description coverage is 67% (model and messages are described, temperature is not). The description adds no extra meaning for parameters, so a baseline score of 3 is appropriate given the moderate schema coverage.

  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: 'Have a conversation with local Ollama for SIMPLE Q&A, factual questions, or basic explanations.' This uses a specific verb ('have a conversation') and resource ('local Ollama'), and the scope ('SIMPLE Q&A...') distinguishes it from sibling tools like code generation or summarization.

  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 guidance is provided: 'Prefer for routine queries to save Claude tokens' and 'AVOID for complex analysis, nuanced discussions, or tasks requiring sophisticated reasoning.' This gives clear when-to-use and when-not-to-use instructions, even though specific sibling alternatives are not named.

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