Server Quality Checklist

Tool Scores

• detach_knowledge_baseA
  4.3/5.0
  Behavior5/5

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

  The description goes well beyond the annotations by explaining the non-destructive nature of the operation, stating that the result reports attachments before and after, and disclosing the multi-prompt agent caveat where the API may accept the change but cannot verify it. This is genuinely useful behavioral context not available from annotations or schema.

  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 with no filler. The primary action is front-loaded, the key limitation is stated immediately after, and the important edge case is saved for the final note. 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?

  For a simple two-parameter detach operation, the description covers the action, the side effects, the result shape, and the main verification caveat. The absence of an output schema is mitigated by the description explicitly saying what the result reports.

  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%, and the two parameters are clearly documented in the schema. The description does not add new parameter-level meaning, but it does not need to since the schema already handles parameter semantics adequately.

  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 and resource: 'Detach a knowledge base from an agent.' It also clarifies the scope by stating it 'only removes the association' and that the knowledge base and its documents remain untouched, distinguishing it from deletion or other destructive operations.

  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 intended use is clear from the title and first sentence, but the description does not explicitly mention when to use this tool versus alternatives such as attach_knowledge_base or list-related tools. The usage context is implied rather than stated with explicit exclusions.

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

• get_knowledge_baseA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true. The description adds valuable behavioral context: it warns that an untrained knowledge base will not answer questions during calls, which explains why the user should check status. 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?

  Two sentences, no filler. The core purpose is front-loaded and the usage warning is actionable. Every word 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?

  With no output schema, the description names the key returned fields (name, status, timestamps, inventory). It also gives the practical context for when to call. For a single-parameter read-only tool, nothing essential is missing.

  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 kb_id parameter is already documented with provenance ('from list_knowledge_bases'). The description does not add parameter-specific meaning beyond the schema, which earns the baseline 3.

  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?

  States a specific verb and resource: 'Get one knowledge base', and enumerates the returned contents (name, processing status, timestamps, inventory of files/URLs/FAQs). This clearly distinguishes it from list_knowledge_bases and the attach/detach siblings.

  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 tells the agent to check the status before attaching the knowledge base to an agent, providing a concrete use case. It does not name alternatives or exclusions, but the context is clear enough for routing.

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

• update_custom_variablesA
  4.4/5.0
  Behavior5/5

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

  The description discloses a non-obvious upstream behavior: the API replaces the entire variable list on every write, so the tool performs a read-modify-write merge that preserves unmentioned variables. This goes well beyond the annotations, explaining why the operation is idempotent and destructive in specific ways. It also clarifies that variables are names only and how prompts reference them.

  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 dense sentences, each adding distinct value: the action, the critical read-modify-write behavior, and the naming/value semantics. No filler, no repetition of schema fields, and the most important behavioral caveat 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?

  For a three-parameter update tool with no output schema, the description covers the key behavioral details needed to invoke it correctly: the merge behavior, preservation of unspecified variables, and the meaning of custom variables. It does not describe return values or error conditions, but those are less critical given the annotations and schema coverage.

  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 schema already documents all parameters with useful descriptions, including the 'already-present names are ignored' behavior. The tool description adds meaning by explaining that variables are names only, values are supplied elsewhere, and prompts reference them via @{{variable_name}}. This enhances an agent's understanding of add and remove beyond the raw 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 opens with a specific verb and resource: 'Add or remove custom variable names on an agent.' This clearly identifies the action and target, and differentiates the tool from siblings like update_agent_prompt or attach_knowledge_base. The scope (agent custom variables) is immediately unambiguous.

  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 makes the operational context clear: use this tool to manage an agent's custom variable names. However, it does not explicitly say when to choose this over alternatives or when not to use it, such as when updating prompts or knowledge bases. Usage is implied rather than stated.

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

• attach_knowledge_baseA
  4.5/5.0
  Behavior5/5

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

  Annotations already mark this as a non-read-only, idempotent, non-destructive operation, and the description adds useful behavioral detail: the result reports attachments before and after, and for multi-prompt agents the API accepts the attachment but cannot verify it. This goes beyond what annotations alone convey and helps the agent interpret the response.

  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 front-loaded with the core purpose, followed by important behavioral semantics and the prerequisite lookup step. Each sentence adds necessary information, and nothing is redundant or filler.

  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?

  The description covers the purpose, the additive behavior, the response shape, an important API edge case, and how to find a required parameter. With no output schema present, this level of detail is sufficient for an agent to invoke the tool correctly.

  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 already documents both agent_id and kb_id, and the schema description coverage is 100%. The description reinforces that kb_id comes from list_knowledge_bases, but it does not meaningfully add new semantic detail beyond the 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 uses a specific verb and resource combination: 'Attach a knowledge base to an agent' and states the intended effect ('so it can answer from those documents during calls'). It also clarifies the additive nature ('does not replace existing attachments'), which differentiates it from the sibling detach_knowledge_base without needing to name it.

  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 provides clear context: the tool is for adding an attachment, is additive, and does not replace existing attachments. It also tells the agent to use list_knowledge_bases to find a kb_id. It does not explicitly say 'use detach_knowledge_base instead when removing an attachment,' but the additive guidance makes the intended selection clear enough.

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

• get_agentA
  4.5/5.0
  Behavior5/5

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

  Annotations already mark readOnlyHint=true, and the description adds genuinely useful behavioral details beyond that: knowledge base attachments are always returned as an array, and the prompt object either reports where its sections were located or explicitly states none were found. This gives the agent concrete expectations about response shape and edge-case behavior.

  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 tightly written sentences front-load the core purpose, then add two high-value behavioral clarifications. Every sentence earns its place with no filler or repetition of schema details.

  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 single-parameter read tool with no output schema, the description fully covers what the caller receives: the configuration components, the guaranteed array shape for knowledge base attachments, and the prompt object's fallback behavior. Nothing necessary for correct invocation or interpretation is missing.

  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?

  There is only one parameter, agent_id, and the input schema already fully documents it as the agent's UUID returned by list_agents (100% schema description coverage). The description does not add parameter-specific detail, 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 opens with a specific verb and resource: 'Get the full configuration of one Ringg agent,' and enumerates the exact contents (prompt sections, custom variables, knowledge bases, voice, languages, tools). The singular 'one' clearly distinguishes it from list_agents, and the domain terms separate it from knowledge-base-only 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?

  The description makes the usage context clear: use this when you need the full configuration for a single agent. It does not explicitly name alternatives or state when not to use it, but the singular scope and enumerated fields give a strong implicit boundary against sibling list tools.

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

• get_callA
  4.5/5.0
  Behavior4/5

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

  Annotations already mark the operation as read-only, and the description goes beyond them by explaining view behavior, defaults, and the 24-hour expiration of recording URLs. This adds meaningful context about response scope and data freshness.

  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?

  Well-structured, front-loaded purpose, and every sentence adds value. The view explanation, usage guidance, and expiration warning are all relevant and efficiently written.

  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 two-parameter read-only tool, the description covers invocation, parameter semantics, output scope, and a key data-freshness concern. No output schema exists, but the view descriptions sufficiently describe what is returned.

  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 the schema documents both parameters, but the description enriches the view enum with concrete meanings (metadata, turns, analysis, full) and advises on size trade-offs. This is more than a bare restatement of the 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?

  States the exact operation ('Get one call by id') and clearly differentiates itself from list_calls by focusing on a single call. The view parameter is explained precisely, making the tool's purpose unmistakable.

  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 guidance on selecting the narrowest view and warns about large transcript/analysis payloads. It does not explicitly contrast with sibling tools like list_calls, but the 'by id' phrasing makes the primary use case clear.

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

• list_agentsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds value by specifying the returned fields (id, display name, type, template info, call count, custom variable names) and the workspace scope, which goes beyond what annotations provide.

  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 filler: the first states the core listing behavior and return shape, the second gives a targeted alternative. The key scoping and differentiation are front-loaded, making the description efficient and easy to parse.

  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, read-only list tool with an output schema absent, the description adequately covers return fields, scope, and the main alternative. Pagination parameters are fully documented in the schema, so nothing needed for correct invocation is missing.

  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%, and both parameters include their own descriptions in the schema. The tool description adds no additional parameter semantics, so the baseline of 3 applies as the schema fully carries the meaning.

  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 states a specific verb and resource: 'List the voice assistants (agents) in the Ringg workspace.' It also differentiates itself from get_agent by mentioning the other tool returns full configuration, so an agent can select the correct tool without confusion.

  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 tells the agent to use get_agent for a single agent's full configuration, providing a clear when-to-use alternative. This is direct sibling routing, leaving no ambiguity about the scope of list_agents.

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

• list_knowledge_basesA
  4.7/5.0
  Behavior4/5

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

  The annotations already mark the tool as readOnlyHint=true, and the description reinforces this by stating the server cannot create, edit, or delete knowledge bases. It adds the workspace-level scope and expected return fields, though it does not mention pagination or error behavior; for a zero-parameter read-only list, this is a minor gap.

  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 earning its place: it front-loads the core listing behavior, then provides alternative tool routing, then states the capability limitation. There is no filler or redundancy.

  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 zero-parameter listing tool with no output schema, the description supplies the scope, the returned fields, alternative routing, and the read-only constraint. Nothing essential for invoking or interpreting this tool correctly 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?

  The tool has zero parameters, so there are no parameter semantics to document beyond the schema. The description does not need to add parameter details, and the baseline for a 0-parameter tool 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 uses the explicit verb 'List' with a specific resource ('knowledge bases'), scopes it to the Ringg workspace, and names the returned fields (id, name, type, creation time). This clearly distinguishes it from get_knowledge_base, which targets a single knowledge base.

  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 routes the agent to get_knowledge_base for a specific knowledge base's document inventory and to attach_knowledge_base for associating one with an agent. This gives clear when-to-use guidance and differentiates the workspace-level listing purpose.

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

• list_callsA
  4.9/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description discloses key behavioral traits: it returns 'SUMMARIES ONLY' with specific fields, and states that transcripts and recording URLs are 'deliberately omitted.' It also imposes an ISO 8601 timezone-offset requirement for dates. These are meaningful behavioral details not present in annotations or schema.

  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, each earning its place: scope, return content, exclusion with alternative routing, and date format requirement. It is front-loaded with the primary purpose and contains no filler.

  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 list tool with 7 optional parameters, no required parameters, and no output schema, the description covers what an agent needs: response content summary, field list, exclusions, date format, and a pointer to the sibling for deeper data. Pagination and defaults are already described in the schema. 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?

  Schema description coverage is 100%, so every parameter is already documented. The tool description adds value by framing all parameters as optional and by giving a concrete date format example, but it does not introduce new per-parameter semantics beyond what the schema already provides. This is slightly above the baseline of 3.

  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 a specific verb and resource: 'List calls from the Ringg workspace with optional filters.' It differentiates itself from the sibling get_call by explicitly noting that transcripts and recording URLs are omitted and that get_call should be used for those, making the tool's scope unambiguous.

  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 gives explicit when-to-use guidance: it says this tool returns summaries only and that get_call is the alternative for a specific call's transcript or analysis. It also provides the required date format with an example, so an agent knows exactly how to supply date filters.

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

• update_agent_promptA
  4.9/5.0
  Behavior5/5

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

  The description goes well beyond the annotations by revealing the read-modify-write behavior, explaining that the upstream API replaces the whole prompt, and clarifying how merge protects unmentioned sections. The destructive nature of replace mode is explicitly disclosed, which is critical and additive context.

  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 dense yet efficient, front-loading the core purpose and then explaining modes with necessary nuance. Every sentence contributes, and the critical safety guidance about the merging behavior is placed up front.

  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 mutation tool with no output schema and a potentially destructive replace mode, this description is complete. It covers preconditions, mode semantics, what gets preserved versus discarded, and the API behavior that motivates the merge. An agent has enough information to call the tool correctly and safely.

  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?

  Since schema description coverage is 100%, the baseline is 3, but the description adds value by explaining the behavior of merge mode and how it relates to the sections parameter. It also reinforces the case-insensitive matching behavior and the need to call get_agent, which supports correct parameter usage beyond the raw 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 names a specific verb and resource ('Update an agent's prompt section by section') and immediately distinguishes the two operational modes. This clearly differentiates the tool from sibling tools like get_agent and list_agents, which are read-only and not prompt modification 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?

  The description explicitly explains when to use merge mode versus replace mode and instructs the agent to call get_agent first to see existing section titles. This gives concrete, actionable guidance for correct tool selection and invocation.

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