@omnidim-ai/mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.9.2
Disambiguation5/5
Each tool targets a distinct resource and action, with detailed descriptions that clearly separate concerns. Even similar operations like list vs. get or different import methods (Twilio, Exotel, SIP) are differentiated. No two tools appear to perform the same function.
Naming Consistency4/5
Most tools follow a consistent verbNoun camelCase pattern (e.g., listAgents, createAgent, deleteAgent). Minor deviations include 'bulkCallActions' (noun phrase), 'canUploadFile' (modal verb), and 'fetchBulkCalls' (fetch instead of list), but the overall pattern remains predictable.
Tool Count2/5
With 49 tools, the server is heavily overloaded, falling into the 'too many' range. It covers a broad domain (agents, calls, bulk calls, phone numbers, knowledge base, providers, reseller), but several tools could be consolidated, such as the multiple import functions and provider list endpoints. This volume can overwhelm agents and hinder efficient tool selection.
Completeness4/5
The tool surface provides strong lifecycle coverage for agents, calls, bulk calls, knowledge base files, and reseller management, including agent versioning and detailed call logs. Minor gaps exist, such as no session listing/deletion and no update/delete for phone numbers, but these are non-critical for the core domain.
Average 3.8/5 across 49 of 49 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, implying a mutation. The description adds no additional behavioral transparency beyond that—it does not disclose whether the import overwrites existing numbers, requires special credentials, or has side effects on the SIP trunk configuration. With annotations present, the description should add context like idempotency or permission requirements, but it does not.
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 core description is a single concise sentence that directly states the action. The appended '(Tags: Phone numbers)' is a minor distraction but does not detract significantly. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex nested requestBody with nine parameters and no output schema, the description is under-specified. It does not explain the import's effect, when it might fail, or how it relates to other phone number tools. The rich schema covers inputs but not behavioral context, leaving the description incomplete.
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% coverage with detailed descriptions for every parameter, including E.164 format and default port 5060. The description adds no extra parameter-level meaning; the baseline of 3 is appropriate because the schema does the heavy lifting.
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 uses the specific verb 'Import' and identifies the resource as 'a phone number associated with a SIP trunk,' which distinguishes it from sibling tools like importTwilioNumber and importExotelNumber. However, the tool name 'importSipTrunk' and title 'Import SIP trunk' create some ambiguity about whether the trunk or the phone number is the primary object, so it is not perfectly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as importTwilioNumber or importExotelNumber. There is no mention of use cases, prerequisites, or conditions that would help an agent choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the response is comprehensive and bundles services and voices into one payload, which is useful context not present in annotations. However, it does not disclose pagination, authentication, rate limits, or what 'services' specifically covers. Annotations already indicate read-only behavior, so the bar for additional transparency is partially met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one meaningful sentence and a tag. It is front-loaded and contains no fluff, making it quick to parse.
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 description is incomplete for a 0-parameter tool with no output schema. It fails to clarify what 'services' means, whether it includes all provider types, or how this tool relates to sibling listing tools. A complete description should at least state that it lists all providers in one call, serving as a combined endpoint.
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?
There are zero parameters, so the schema fully covers parameter semantics (100% coverage). The description need not explain parameters; a baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Comprehensive response with services and voices in one payload' lacks a clear verb and does not explicitly state that the tool lists all providers. The tag 'Providers' hints at the resource, but the purpose is vague and could apply to several 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like listLLMProviders or listVoices, nor does it provide any exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe read operation. The description adds no behavioral context beyond annotations—it only restates the schema's filtering capability without disclosing return format, permissions, or other runtime behavior.
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, front-loaded sentence that clearly states the action and scope. The parenthetical '(Tags: Calls)' is minor noise but does not detract significantly. Overall, it is concise and structured for quick readability.
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 list tool with well-documented optional parameters and read-only annotations, the description is minimally adequate. However, it does not describe the return value or any sorting/default behavior, and with no output schema, the agent must assume the response contains a list of call logs.
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 each parameter already has a clear meaning. The description mentions 'pagination and optional filtering' at a high level, which aligns with the schema but adds no per-parameter details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and resource 'call logs', indicating a listing operation. It mentions pagination and filtering, which clearly distinguishes it from getCallLog (retrieving a single log). However, it doesn't explicitly name siblings, so it's clear but not fully differentiated.
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 is provided on when to use this tool versus alternatives like getCallLog. The mention of pagination implies use for listing multiple records, but there is no explicit when-to-use or when-not-to-use statement, nor any mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral detail added beyond the annotations is the Base64 encoding requirement, which is already present in the schema's parameter description. The description does not disclose what happens on success, whether there are file size limits, if the upload is asynchronous, or what the response contains. Since there is no output schema, this omission is significant.
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 short and front-loaded, with two direct sentences plus a redundant tag. Every sentence carries some weight, though the tag '(Tags: Knowledge base)' is unnecessary given the tool name.
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 lacks an output schema, so the description should explain the return format or success indication, but it does not. It also omits reference to canUploadFile, which exists as a sibling and likely serves as a prerequisite. The nested requestBody structure is only clarified in the schema, leaving the agent without enough context for a complete invocation.
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% — both 'file' and 'filename' have descriptive text. The tool description reiterates 'PDF' and 'Base64' but adds no new semantic information beyond what the schema already provides. Baseline 3 is appropriate.
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 action 'Upload' and the target resource 'a PDF file', making the tool's purpose unambiguous. It is distinct from sibling tools like listKnowledgeBaseFiles and deleteKnowledgeBaseFile, although it could more explicitly tie it to the knowledge base context beyond the tag.
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 guidance on when to use this tool versus alternatives such as attachKnowledgeBaseFiles or canUploadFile. It does not mention any prerequisites, workflow steps, or exclusions, leaving the agent to infer the intended usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation. However, the description adds no extra behavioral context: it doesn't disclose whether attaching files replaces existing attachments or appends to them, whether it requires the agent to exist, or what side effects occur. The description simply restates the core action without additional nuance.
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 that immediately conveys the purpose. The parenthetical tag 'Knowledge base' is slightly redundant but harmless. There is no waste or filler, and the most important information is front-loaded.
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?
While the schema provides parameter details, the description is incomplete for a mutation tool. It does not explain whether the operation is additive or replacing, what happens to existing file attachments, or what the response indicates. There is no output schema to fall back on. Given the complexity and lack of behavioral detail, the description leaves important gaps for an agent to select and 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 covers 100% of parameters, including descriptions for agent_id, file_ids, and when_to_use. The tool description adds no additional parameter meaning beyond the schema. According to the rubric, with high schema coverage, a 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 a specific action: 'Attach multiple knowledge-base files to an agent.' It identifies the resource (knowledge-base files), the target (an agent), and the operation (attach). This distinguishes it from sibling tools like detachKnowledgeBaseFiles, uploadKnowledgeBaseFile, and listKnowledgeBaseFiles.
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 guidance on when to use this tool versus alternatives, such as uploadKnowledgeBaseFile for uploading new files or detachKnowledgeBaseFiles for removing attachments. It only includes a 'Knowledge base' tag, which hints at context but does not explicitly state prerequisites, exclusions, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the destructiveness is known. However, the description adds no additional behavioral context, such as whether cancellation is irreversible, what happens to ongoing calls, or if any confirmation is needed. It simply restates the purpose without disclosing side effects beyond what annotations already indicate.
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, direct sentence followed by a tag. It is extremely concise, front-loaded, and contains no wasted words. Every part earns its place, making it easily scannable.
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 cancellation tool with one parameter and annotations, the description is adequate but not thorough. It omits behavioral nuances like what happens to already-placed calls or whether cancellation is reversible. Given the destructive nature (annotations), some additional context would improve completeness, but the tool's simplicity keeps this from being a failing 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?
The schema has 100% coverage, with bulk_call_id described as 'Id of the bulk call campaign.' The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate. No additional parameter context is needed for this simple one-param tool.
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 "Cancel" and the resource "bulk-call campaign," which is specific and distinguishes it from sibling tools like createBulkCall, getBulkCall, or bulkCallActions. The purpose is immediately obvious.
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 guidance on when to use this tool versus alternatives. It does not mention conditions for cancellation, prerequisites, or contrast with similar tools like bulkCallActions, which might also modify campaign state. The intended use case is only implied by the verb 'cancel.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the concept of taking a snapshot of current configuration, which is useful but does not elaborate on side effects (e.g., whether it overwrites an existing version with the same name, limits on versions, or permissions required). It does not contradict annotations.
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 sentence with a tag, which is very concise. It wastes no words, but the tag '(Tags: Agents)' adds little value. The information is front-loaded, but slightly more detail could be added without sacrificing conciseness.
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 (2 required parameters, no output schema), the description is mostly adequate. However, it lacks information about the return value (e.g., the created version object or ID). For a creation tool, the agent would benefit from knowing what to expect as a response. Prerequisites (agent existence) are also implied but not stated.
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 schema already documents agent_id and requestBody (including name and note). The description reinforces that the version is a snapshot of the current configuration, but does not add new parameter-level meaning beyond what the schema provides. 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 saves the agent's current configuration as a named version, using a specific verb ('Save') and resource ('agent's current configuration'). It distinguishes from sibling tools like createAgent, updateAgent, listAgentVersions, and restoreAgentVersion by focusing on version creation as a snapshot.
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 is provided on when to use this tool versus alternatives. For example, it does not mention that the agent must already exist, that this should be called after updating configuration, or that it is distinct from listAgentVersions or restoreAgentVersion. The agent has no context to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive operation. The description's verb 'Delete' is consistent. However, it adds no extra behavioral context (e.g., permanence, required permissions, side effects) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short: one sentence plus a tag. It is front-loaded with the core action. However, the tag appears to be metadata leaking into the description, which is slightly distracting. It could add a bit more substance without becoming verbose.
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 simple tool (2 well-documented params, no output schema, clear annotations), the description is adequate but not fully complete. It could mention that deletion is permanent, or specify that version_number must come from list/save endpoints (which is already in the schema). The description provides minimal contextual supplementation.
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%, with both agent_id and version_number documented in the schema itself. The description does not add any additional meaning or context about the parameters. Baseline 3 is appropriate because the schema carries the burden 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 'Delete a saved version' clearly states the verb (delete) and resource (a saved version of an agent). The title from annotations reinforces this. It distinguishes from siblings like renameAgentVersion and listAgentVersions by naming the delete action.
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 is provided on when to use this tool vs alternatives. For example, there is no mention that this deletes a specific version rather than the entire agent (for which deleteAgent exists). The description lacks usage context, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, so the destructive nature is already known. However, the description adds no additional behavioral context such as reversibility, effects on the agent, or permissions needed. It merely restates the action without enriching the annotation.
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 that conveys the essential action without any filler. It is ideally concise and well-structured for quick comprehension.
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's simplicity (one parameter, no output schema) and the destructive annotation, the description is adequate. It could mention prerequisites (e.g., phone number must be attached) but is otherwise complete for an experienced user.
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% coverage with a clear description for 'phone_number_id', so the baseline is 3. The tool description does not add any extra semantic detail about the parameter 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 action ('Detach') and the resource ('a phone number from its associated agent'), making the purpose unambiguous. It also differentiates from sibling tools like attachPhoneNumber or listPhoneNumbers by specifying the reverse operation.
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 is provided on when to use this tool versus alternatives such as attachPhoneNumber. The description only states the action without any context on prerequisites or when this operation is appropriate, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond the readOnlyHint and openWorldHint annotations. It does not disclose return format, permissions, or edge cases, but the annotations adequately cover the safety profile, so the description is not misleading.
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 concise sentence with no filler or redundant content. It front-loads the core purpose and avoids unnecessary details, which is ideal for a simple lookup tool.
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 get-by-ID tool, the description, schema, and annotations together provide adequate context. However, without an output schema, the description could specify what metadata is included (e.g., name, provider, languages) to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a descriptive explanation for voice_id. The tool description adds no parameter-level information, so the baseline of 3 is appropriate given the schema already handles the semantics.
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 returns detailed metadata for a specific voice, implying a retrieval operation. It distinguishes from sibling tools like listVoices by targeting a single voice, though the verb is implicit rather than explicit.
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 is provided on when to use this tool versus alternatives such as listVoices or when it would be appropriate. The use case is only implied by the 'specific voice' wording, with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It says 'Retrieve all' which restates the readOnlyHint. There is no mention of response format, pagination, rate limits, or what the 'all' list contains. The openWorldHint=false is not explained. Given annotations already declare read-only, the description contributes little.
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 concise and front-loaded with the main action in the first sentence. The parenthetical tag '(Tags: Providers)' is arguably unnecessary but does not distract. It is appropriately sized for a trivial tool.
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 no-parameter read-only list, the description is minimally adequate. However, it does not indicate the shape of the response (e.g., array of provider objects with ids/names) or any behavior like sorting or empty results. With no output schema, this information would be helpful. But given the simplicity, a score of 3 is reasonable.
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?
With zero parameters, there is nothing for the description to clarify. The schema is trivially complete (100% coverage). The description adds no parameter info but none is needed. Baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'Speech-to-Text providers', distinguishing it from sibling tools like listLLMProviders and listTTSProviders. The meaning is unambiguous, though it does not mention alternatives.
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 usage context or alternatives are provided. The description simply states what it does with no guidance on when to prefer this over listAllProviders or other provider lists. For a tool with no parameters, there is also no mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds that the tool initiates a real call, which is helpful, but does not disclose potential side effects like billing or call duration. With annotations covering the safety profile, the description adds minimal extra behavioral 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 two sentences long, front-loaded with the primary action, and includes a necessary formatting constraint. It contains no fluff or redundancy, making it highly concise and well-structured.
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 tool with a rich schema and annotations, but it lacks any mention of what happens after the call is initiated (e.g., returns a call ID or status). Given there is no output schema, a brief note on the expected response 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?
Schema description coverage is 100%, and the schema already documents all parameters including agent_id, to_number, call_context, and from_number_id. The description adds no new parameter semantics beyond restating the country code requirement already present in the schema, so the 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 uses a specific verb 'Initiate' and clearly identifies the resource: a call to a phone number using a specified agent. This distinguishes it from sibling call-related tools like listCallLogs or createBulkCall, which handle different operations.
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 guidance on when to use this tool versus alternatives such as createBulkCall for bulk calls or listCallLogs for viewing calls. The only usage hint is the prerequisite that the phone number must include a country code, but that is a formatting instruction rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, making the read-only nature transparent. The description adds behavioral details about pagination and status filtering, which go beyond the annotation. However, it does not disclose the response format, any authorization requirements, or potential rate limits, but given the annotation coverage, the added context 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 concise and front-loaded with the verb 'List'. The parenthetical '(Tags: Bulk calls)' is somewhat redundant with the tool name but does not significantly clutter the description. Overall, every sentence contributes to the core purpose without excessive verbosity.
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 read-only list operation with three well-documented optional parameters, the description covers the essential aspects: purpose, pagination, and filter capability. It does not detail the return structure, but the lack of an output schema and the tool's simplicity make this acceptable, especially with the readOnlyHint annotation.
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 detailed descriptions for all three parameters, including types, defaults, and constraints. The description's mention of 'optional status filter' merely echoes the schema's status parameter description without adding new meaning, so it does not surpass the baseline for high 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 uses the specific verb 'List' and identifies the resource as 'bulk-call campaigns', further specifying pagination and optional status filtering. This clearly differentiates it from siblings like getBulkCall (single resource) and createBulkCall (creation), leaving 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives. While sibling tool names imply a distinction (e.g., getBulkCall for a single campaign), the description itself offers no when-to-use or when-not-to-use context, nor does it mention any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-destructive operation. The description adds that credentials are required, which is useful context, but does not disclose side effects or expected results. With annotations already covering safety, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and to the point, but includes a redundant '(Tags: Phone numbers)' line that adds no value. Otherwise efficient and front-loaded.
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?
For an import operation with no output schema, the description is too sparse; it doesn't mention what the output or response will be, nor any side effects or prerequisites beyond credentials. The nested request body is fully documented in schema, but the lack of behavioral context makes it incomplete.
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 schema fully describes all parameters with descriptions and required fields, so the description need not add parameter details. Baseline 3 is appropriate as the description adds no extra meaning 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?
Clearly states it imports an Exotel number, using a specific verb and resource. The mention of Exotel credentials distinguishes it from sibling import tools like importTwilioNumber and importSipTrunk.
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?
Implied usage: use when you have Exotel credentials and want to import an Exotel number. No explicit exclusions or comparison to alternatives, but the name and description are sufficiently specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive. The description adds the specific action types (pause/resume/reschedule) and the scope 'running campaign,' but it does not disclose side effects, permission requirements, or rate limits. It complements annotations without contradicting 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?
The description is concise, with the core action list immediately clear. The trailing '(Tags: Bulk calls)' is somewhat redundant and adds little value, but it does not detract significantly from the overall clarity.
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?
While the schema covers parameter details, the description lacks important contextual information for a complex mutation tool: it does not clarify that 'reschedule' requires additional parameters (new_scheduled_datetime) or mention what happens after the operation (e.g., return value or side effects on the campaign). The description is adequate but under-specified for a tool with a nested request body and action-dependent parameters.
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 full descriptions for all parameters, including the action enum and the conditional fields (new_timezone, new_scheduled_datetime). The description adds no additional parameter-level detail beyond what the schema already documents, so the 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 clearly states the tool's function: 'Pause, resume, or reschedule a running campaign.' It uses specific verbs and identifies the resource (a campaign), and it distinguishes itself from sibling tools like cancelBulkCall and fetchBulkCalls by focusing on control actions rather than listing or canceling.
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 provides no explicit guidance on when to use this tool versus alternatives, such as cancelBulkCall. The phrase 'running campaign' implies a precondition, but there is no mention of when not to use it or when another tool would be more appropriate. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already indicates a safe read operation, and the description is consistent. However, the description adds no extra behavioral context—e.g., what 'detailed information' includes, error behavior, or pagination—beyond the annotation.
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, front-loaded sentence with no redundant content. The tag '(Tags: Bulk calls)' is minor but does not detract from 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?
For a simple get-by-id tool with one required parameter and a read-only annotation, the description is nearly complete. The phrase 'detailed information' hints at the return value but could be more explicit about the response shape since no output schema is provided.
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 schema fully documents the only parameter bulk_call_id with an adequate description. The tool description adds no additional meaning beyond the schema, so the baseline 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 uses a specific verb ('Get') and resource ('bulk-call campaign') with a clear modifier ('detailed information'). This distinguishes it from sibling tools like getBulkCallLiveStatus, which focuses on live status rather than general details.
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 is provided on when to use this tool versus alternatives such as getBulkCallLiveStatus or fetchBulkCalls. The description states what the tool does but gives no context for choosing it over other bulk-call tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds useful context about 'account-owned' phone numbers and 'existing agent,' but omits side effects, failure modes, or multi-attachment behavior. Adequate but not thorough.
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 main sentence is concise and front-loaded, but the trailing '(Tags: Phone numbers)' is extraneous and does not earn its place. Otherwise, the structure is efficient.
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 operation is simple: one nested object with two well-documented parameters, no output schema. The description provides the key constraints (account-owned, existing agent). Could mention whether the number must be unattached, but is otherwise complete for this scope.
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% for both parameters (agent_id, phone_number_id), so the schema fully documents them. The description adds no additional parameter-level detail, justifying the baseline score 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 clearly states the specific action: 'Attach an account-owned phone number to an existing agent.' This distinguishes it from the sibling tool 'detachPhoneNumber' and accurately conveys the resource being modified.
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?
Usage is implied by the action, but the description does not explicitly state when to use this tool versus alternatives like 'detachPhoneNumber' or any prerequisites/exclusions. No when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns by using 'Check'. It adds a small amount of context by specifying that eligibility depends on size and type, but it does not disclose behavior such as response format, limits, or whether it checks workspace restrictions. With annotations present, the bar is lower, and the description provides only minimal additional value.
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 concise sentence plus a tag. Every word earns its place, and the structure is clean and front-loaded with the verb and resource.
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 tool is simple, and the schema covers parameters well, but the description lacks details about the expected output or any size limit knowledge. Since there is no output schema, the agent does not know whether the response is a boolean, a reason, or a status. It is complete enough for a basic check, but missing context that could affect invocation.
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%; file_size and file_type have descriptive text including 'Only pdf is accepted.' The description's mention of 'size and type' duplicates what the schema already provides. No additional parameter meaning is added.
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: 'Check whether a file can be uploaded based on size and type.' It uses a specific verb (Check) and resource (a file) and specifies criteria (size and type). This distinguishes it from sibling tools like uploadKnowledgeBaseFile, which performs the actual upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for validation before upload but does not explicitly state when to use it versus alternatives. It lacks an explicit mention of uploadKnowledgeBaseFile or any exclusions. The context is clear enough for an agent to infer, but there is no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds context about requiring Twilio credentials, which is also present in the schema. It does not disclose side effects, idempotency, or ownership checks, so it adds minimal behavioral value beyond 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 a single sentence that front-loads the action and requirement. It contains no redundant information, and the tag is harmless.
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 import tool with a nested object schema, the description is adequate but minimal. It doesn't explain the outcome of the import, potential error conditions, or how the imported number will be used (e.g., for later attachment). Given the lack of an output schema, the agent might benefit from more context, but the core operation is clear enough.
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%, with clear descriptions for phone_number, account_sid, account_token, and name. The description's mention of 'credentials' loosely maps to the SID and token but adds no detail beyond the schema, so it doesn't enhance parameter 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 action ('Import'), the resource ('existing Twilio number'), and the method ('providing your Twilio credentials'). This distinguishes it from sibling tools like importExotelNumber and importSipTrunk, which target different providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (importing a Twilio number with credentials) but does not explicitly compare to alternatives or state when not to use it. There is no mention of prerequisites or exclusions, leaving the agent to infer from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, signaling a safe read operation. The description adds value by specifying that versions include manual, auto, and system backups, and that results are ordered newest first. This goes beyond the annotations without contradicting them, providing useful behavioral 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 extremely concise: two sentences covering purpose, ordering, version types, and a tag. Every sentence contributes meaning, with no redundant or extraneous text. This is a model of efficient communication.
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 absence of an output schema, the description should help the agent understand what the tool returns. It mentions ordering and version types but does not describe the structure of returned objects (e.g., fields like id, name, kind). While the tool is straightforward, the lack of output details leaves a gap for agents needing to parse results.
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 input schema already documents all 5 parameters thoroughly. The description does not add parameter-level details beyond the general purpose. Baseline of 3 is appropriate as the description adds no additional semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('an agent's saved versions'), specifies ordering ('newest first'), and enumerates included version types (manual, auto, system backups). This effectively differentiates from sibling tools like listAgents (lists all agents) and getAgent (single agent), 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as listAgents, getAgent, or version management tools. There are no explicit when-to-use, when-not-to-use, or alternative recommendations, leaving the agent to infer usage context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already include destructiveHint=true, so the destructive nature is known. The description adds 'permanently', reinforcing irreversibility, but does not disclose potential side effects like deletion of related versions or sessions. 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 one short sentence followed by a tag. It is front-loaded, concise, and contains 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 simple one-parameter schema, the destructive annotation, and clear purpose, the description is nearly complete. The only gap is a lack of mention of cascading effects (e.g., deleting agent versions), but this is not critical for a basic delete 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%: the only parameter agent_id is described as 'The ID of the agent.' The description adds no additional meaning beyond the schema, so baseline 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 clearly states 'Permanently delete an agent' with a specific verb and resource. It distinguishes from sibling tools like deleteAgentVersion and deleteKnowledgeBaseFile by targeting the agent itself.
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 provides no explicit when-to-use or alternatives. Usage is implied by the tool's name and purpose, but there is no guidance on choosing this over other delete-related sibling tools such as deleteAgentVersion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds context that this is for 'running' campaigns and provides 'real-time' status, which is useful but does not disclose additional behavioral traits such as what fields the status includes or behavior if the campaign is not running.
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, front-loaded sentence that states the core purpose without unnecessary detail. The tag 'Bulk calls' adds little but is not distracting. Every word earns its place.
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, read-only tool with one parameter and no output schema, the description is adequate. It conveys the key constraint ('running') and the real-time nature. However, it could be more complete by hinting at what status information is returned, but the low complexity level means this is not a major gap.
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% for the single parameter (bulk_call_id), and the schema already describes it as 'Id of the bulk call campaign.' The description does not add any additional meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving real-time status of a running bulk-call campaign, with a specific verb ('status') and resource ('bulk-call campaign'). It distinguishes from siblings like getBulkCall by emphasizing 'running' and 'live', though it does not explicitly name alternatives.
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 appropriate use cases: use when you need the current live status of an ongoing bulk-call campaign. It does not provide explicit exclusions or alternatives, but the context is clear enough for an agent to differentiate from listing or general retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description doesn't need to restate that. It adds context about return content (transcript, sentiment, extracted variables), but does not disclose any behavioral limitations or permissions. Adds some value beyond the annotation.
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 one sentence, front-loaded with purpose, and includes a useful parenthetical list of returned fields. The 'Tags: Calls' is minor extra but not detrimental. No redundant content.
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 single-parameter read tool with no output schema, the description gives a solid overview of return contents. It could mention error handling or the exact response shape, but the listed fields and specificity are sufficient for most agents.
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 single parameter call_log_id is fully described in the schema with clear provenance ('as returned by the call log list'). The tool description does not add new meaning, so baseline 3 applies given 100% 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 retrieves detailed information about a specific call, enumerating key data points (duration, status, transcript, sentiment, extracted variables). This distinguishes it from sibling list/bulk call tools by focusing on a single resource's details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single-call lookups via 'specific call', but it does not explicitly state when to use this over listCallLogs or fetchBulkCalls, nor does it mention exclusions or prerequisites. Context is present but not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows it is a safe read operation. The description adds the authentication scope, which is useful but minimal. It does not mention pagination, result format, or rate limits.
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?
One sentence, front-loaded, no wasted words. The tag adds minor context but does not detract.
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 zero-parameter, read-only list tool, the description covers the essentials. It lacks output schema details, but that is not necessarily required given the simplicity.
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?
There are no parameters and the schema is empty, so the description carries no burden. Baseline 4 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 a specific action ('List') with a resource ('knowledge-base files') and scope ('for the authenticated user'). It distinguishes from siblings like upload/delete/attach by its listing nature.
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 alternatives. While it is the listing counterpart to upload/attach/delete, there is no explicit context or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only nature is disclosed. The description adds account scoping but does not mention pagination behavior or response format, going slightly beyond annotations but not richly.
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 clear sentence with a minimal tag suffix. It is front-loaded with the purpose and contains no redundant content.
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 paginated list tool with strong annotations and full schema coverage, the description provides sufficient context to select and invoke the tool. Minor gap: no mention of response shape, but no output schema exists and the behavior is straightforward.
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?
Both pageno and pagesize have detailed schema descriptions with defaults and ranges, achieving 100% schema description coverage. The description adds no parameter-specific information beyond the schema, so baseline 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?
Description uses a specific verb 'Retrieve' and resource 'all phone numbers associated with your account', clearly distinguishing it from sibling operations like attach, detach, or import phone numbers.
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?
Usage is implied by the phrase 'Retrieve all phone numbers associated with your account', but there is no explicit when-to-use guidance or comparison with alternatives like listKnowledgeBaseFiles or detachPhoneNumber.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which indicates a safe read operation. The description adds that the diff is 'record-level' and explains the comparison modes. It does not disclose any other behavioral traits such as authorization requirements or rate limits, but given the read-only nature, it is sufficient.
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 the first sentence immediately stating the purpose. Each subsequent sentence adds specific information about the default behavior and the 'against' parameter. There is no redundant information, and the tag line is minimal.
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 tool has no output schema, so the description should ideally describe the return value. It does not specify what the diff format looks like (e.g., list of changes, unified diff). While the description is adequate for basic usage, the lack of output description leaves a gap for the agent to understand the response structure.
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 input schema has 100% coverage, with detailed descriptions for each parameter. The description adds value by explaining the default comparison and the semantics of 'against=current' (what restoring would change), which goes beyond the schema's 'agent's live config'. This additional context helps the agent understand the parameter's effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and the resource 'record-level diff' for this version. It clearly states the action and the object. Among sibling tools, no other tool provides diff functionality, so it is well-distinguished.
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 explains the default behavior (comparing with previous version) and provides examples for the 'against' parameter. However, it does not explicitly state when to use this tool versus alternatives like restoreAgentVersion or listAgentVersions, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, establishing the safety profile. The description goes beyond this by noting the response includes a `version_history_enabled` boolean and linking to docs. However, it does not discuss error behavior, response structure beyond that one field, or any other behavioral nuances, so the added value is moderate.
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, front-loaded sentence that immediately states the action and resource. It then adds a useful note about a response field and a docs link. There is no redundancy or fluff, making it exceptionally concise and well-structured.
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?
This is a simple get-by-ID tool with one parameter fully documented and read-only annotations provided. The absence of an output schema means the description should ideally convey the response shape; it mentions `version_history_enabled` but does not outline the complete agent object or error cases. Given the low complexity, the description is adequate but leaves some ambiguity.
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 fully covers the single parameter `agent_id` with type, required flag, and a description ('The ID of the agent'). The tool description merely restates 'by ID' without adding details about the ID's source, format, or constraints. With 100% schema coverage, the description adds minimal value beyond the schema, warranting the baseline score 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 clearly states the tool's purpose: 'Get details of a specific agent by ID.' This specific verb-resource combination distinguishes it from siblings like listAgents (list all), updateAgent, and deleteAgent. It also adds a specific response detail (version_history_enabled), further clarifying its behavior.
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: it is used to retrieve details for a single agent given its ID, implicitly distinguishing it from listAgents. It does not explicitly mention alternatives or exclusions, so it falls short of a 5, but the context is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, and the description consistently describes a mutating operation. The description adds minimal behavioral context, such as the ability to detach multiple files at once, but does not disclose side effects or reversibility beyond what the annotations convey. It does not contradict the 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 a single sentence that directly states the operation, followed by a useful tag. No filler or irrelevant information. It is appropriately front-loaded and concise.
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 a simple nested structure with two required parameters, fully described in the schema. Annotations indicate it is destructive, and the description clarifies the operation. Without an output schema, no return-value documentation is expected. The combination of description, schema, and annotations provides sufficient context for an agent to use 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 schema provides 100% coverage with descriptions for both agent_id and file_ids. The tool description adds no additional parameter details, but the schema descriptions are self-explanatory. Baseline 3 is appropriate given full 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 states 'Detach multiple knowledge-base files from an agent' with a specific verb (detach), resource (knowledge-base files), and target (agent). This clearly distinguishes from sibling tools like attachKnowledgeBaseFiles (opposite) and deleteKnowledgeBaseFile (delete vs detach).
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 clearly implies the use case: when you need to remove knowledge-base files from an agent. However, it does not explicitly mention alternatives or exclusions, such as when to use deleteKnowledgeBaseFile instead of detach. The context is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds important behavioral context beyond that: permanence ('Cannot be undone') and the side effect on attached agents. This gives the agent a fuller picture of the operation's consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using three short sentences to convey action, side effects, and irreversibility. Every word earns its place, and the (Tags: Knowledge base) suffix adds contextual metadata without bloat.
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 delete operation with one well-documented parameter, the description is complete: it states the action, the permanent nature, and the agent detachment side effect. Annotations cover the destructive profile, and no output schema is needed, so no further explanation is required.
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% for the single file_id parameter, which already documents its meaning. The description adds no extra parameter details, so the baseline of 3 is appropriate; it neither needs nor provides further elaboration.
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 identifies a specific action ('Permanently delete a file') and resource ('a file' in the knowledge base context). It also distinguishes from siblings like detachKnowledgeBaseFiles by noting the file is removed from attached agents, making the scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the side effect ('Removes it from any attached agents'), which hints at when to use this vs detach, but it does not explicitly name alternatives or state when not to use. No direct comparison to sibling tools is provided, so usage guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral details beyond that: pagination support and authenticated user scoping. It does not contradict annotations and adds value by explaining the listing mechanism.
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 front-loaded with the key action and resource. It is concise with no unnecessary fluff, though the parenthetical tag '(Tags: Agents)' is slightly redundant, it does not significantly detract from the clarity.
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?
While the tool is simple and annotations are good, the description omits the name filter capability that is a key feature in the schema. It also doesn't describe the return format (no output schema), but one would expect a list of agents. The omission of filtering makes it less complete than it could be.
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 schema already fully describes the parameters. The description mentions pagination but does not add any parameter-specific meaning beyond what's in the schema, so a 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 action ('Retrieve'), the resource ('all agents'), and the scope ('for the authenticated user'), making it easy to distinguish from siblings like getAgent (single agent) and createAgent. The pagination support is also mentioned, which adds specificity.
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 for when to use the tool (listing agents for the authenticated user), and the pagination note implies usage for large datasets. However, it does not explicitly state alternatives or when not to use it, though the sibling list makes this fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds the 'all' scope. However, it does not disclose possible behavioral traits like pagination, response shape, or whether only active providers are returned. No contradiction exists.
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, front-loaded sentence that states the purpose clearly. The 'Tags: Providers' suffix is minor and does not detract from conciseness.
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, read-only list tool with strong annotations and no output schema, the description sufficiently conveys what is retrieved. No critical information is missing for basic selection and invocation.
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?
With zero parameters and 100% schema coverage, the description has no additional parameter semantics to convey. The baseline of 4 is appropriate for a parameterless tool.
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 ('Retrieve') and a clear resource ('all Text-to-Speech providers'). It distinguishes from sibling tools like listLLMProviders and listSTTProviders by explicitly naming the TTS domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when TTS providers are needed, but it provides no explicit when-to-use guidance or alternatives. It does not mention that listAllProviders exists for a combined provider view, so differentiation is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly=false, destructive=true), the description adds that the contact is 'queued immediately, and the campaign starts calling it as soon as it is within operating hours,' revealing real-time queueing and scheduling behavior. It also explains the lifecycle of dynamic campaigns, which is valuable context not in 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 front-loaded with the main action. The second sentence adds essential context about dynamic campaigns and the webhook use case, and the final sentence covers behavior. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with nested objects and no output schema, the description covers the workflow well: dynamic campaign creation, webhook feeding, queueing, and operating hours. It doesn't mention response format or error scenarios, but the annotations and schema provide sufficient context for an agent to invoke it 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?
Schema description coverage is 100%, and the tool description adds no additional parameter-level meaning beyond what the schema already provides. Baseline 3 applies because the schema does the heavy lifting.
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 exactly what the tool does: 'Push a single contact into a dynamic bulk-call campaign in real time.' It distinguishes this from siblings by explaining that dynamic campaigns are created from the dashboard and this webhook is how you feed them from a CRM, form, or automation platform, clearly separating it from bulk-call creation or management 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 provides clear when-to-use context: dynamic campaigns stay alive waiting for contacts, so this is the webhook to feed them from external platforms. However, it does not explicitly name alternative tools or state when not to use it, stopping short of full 5-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-destructive operation. The description adds valuable behavioral context by stating that the new organization is automatically linked to the reseller account, which is beyond what the schema or annotations provide. No contradictions.
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 (two sentences plus a tag). The first sentence states the core action, the second reveals an automatic side effect, and the tag gives domain context. 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 the fully described nested schema and no output schema, the description adequately covers what the tool does. It could mention response behavior, but that is not required without an output schema. The reseller context is clear.
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% with all properties detailed. The tool description itself does not elaborate on parameters, so the baseline of 3 applies since the schema does the heavy lifting.
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 'Create' and names the resource 'new child user and organization under the reseller', clearly distinguishing it from sibling tools like listChildOrganizations or createAgent. The (Tags: Reseller) further reinforces the domain.
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 context is clear: this is for creating a new child user and organization under a reseller. It doesn't explicitly mention alternatives or exclusions, but the action is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that voicemail detection is access-gated and requires per-account enablement, which is a behavioral trait not covered by annotations. Does not mention other side effects or 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?
Concise and well-structured: a clear opening sentence, a summary of capabilities, and a focused note on voicemail access. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with a large nested schema, the description provides a useful overview and highlights the key access caveat. However, it does not mention the return value or potential errors, but the schema itself is very detailed.
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 gives a high-level summary of supported features but does not add meaningful detail beyond the already extensive parameter descriptions in the schema, which has 100% 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?
Clearly states it creates a new agent with configuration, and lists the key capabilities. Distinguishes from sibling tools like updateAgent and deleteAgent.
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?
Implicitly indicates when to use (to create an agent) and provides a specific usage note about voicemail access-gating, but lacks explicit comparisons to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds no significant behavioral details beyond restating the scope. The phrase 'all available' is consistent with openWorldHint=false but doesn't provide new information. No contradictions.
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 core sentence is concise and front-loaded, but the 'Tags: Providers' suffix is unnecessary fluff. Overall, the description is efficient but not perfectly waste-free.
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 no parameters and no output schema, the description is sufficient. It clearly states what the tool returns (all available LLM providers) and the annotations cover safety and world-openness. No additional context is needed.
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 the baseline is 4. The description doesn't need to add parameter details since there are none, and the schema is trivially covered.
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 'retrieve' and the resource 'all available Large Language Model providers,' making the tool's purpose unambiguous. It also differentiates from sibling tools like listSTTProviders and listTTSProviders by explicitly focusing on LLM providers.
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 usage when LLM providers are needed, and the name reinforces this. However, it doesn't explicitly compare against alternatives like listAllProviders or mention when not to use it. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses important behavioral differences: ElevenLabs allows advanced filtering by name, language, accent, and gender, while other providers only support pagination. This goes beyond annotations by explaining provider-specific constraints, though it stops short of detailing behavior when provider is omitted.
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: the first states the core purpose, the second adds provider-specific context. The 'Tags: Providers' suffix is minor but does not detract. Every word earns its place with no 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?
Given the tool's moderate complexity (7 optional params, provider variations) and lack of an output schema, the description covers the key nuance: which providers support advanced filtering vs basic pagination. It does not describe return structure, but the schema covers parameters and the name implies a voice list, making this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all 7 parameters (100% coverage), including 'ElevenLabs only' labels. The description's mention of 'advanced filtering' simply summarizes the schema without adding new meaning, so it meets the baseline but does not exceed it.
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 retrieves voices with filtering and pagination support, using a specific verb and resource. It also distinguishes provider-specific capabilities, setting it apart from sibling tools like getVoice (single voice) and listTTSProviders (providers).
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 for when to use the tool and what to expect across providers ('ElevenLabs supports advanced filtering... Other providers support basic pagination only'). It does not explicitly name alternative tools for single-voice retrieval, but the provider-specific guidance serves as practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds valuable context that version history is otherwise immutable, clarifying that only name and note can change. 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?
Two sentences front-load the action and then add essential context about immutability. No filler or redundancy; every word earns its place.
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 rename/edit operation with three well-documented parameters and no output schema, the description is complete. It explains the scope of changes and the immutable context. Could optionally note the return behavior, but not necessary.
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 clear parameter descriptions. The description does not add additional semantic guidance beyond what the schema already provides, so 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 explicitly states the tool renames or edits the note of a saved version, which is a specific action on a clear resource. It distinguishes from sibling version tools (list, create, delete, diff, restore) by focusing solely on metadata changes.
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 notes that version history is immutable except for name and note, implying that this tool is the only way to modify metadata. However, it does not explicitly contrast with siblings like createAgentVersion or restoreAgentVersion, nor state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by explaining that a backup is automatically saved (making restoration undoable) and detailing that deleted knowledge files/integrations cannot be re-linked and are reported in a `skipped` field. This adds critical behavioral context not covered by 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 two sentences plus a tag, front-loading the action and adding essential details about reversibility and limitations. Every sentence serves a purpose with 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?
The description covers the core behavior, side effects, and a field in the response (`skipped`). Without an output schema, it provides sufficient information for an agent to decide when to use the tool, though a bit more detail on the full response structure 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?
Schema coverage is 100% and the description adds no additional meaning beyond what the schema already provides for agent_id and version_number. The baseline of 3 is appropriate given the high 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 restores a version onto the live agent, with a specific verb and resource. It distinguishes itself from sibling tools like listAgentVersions and deleteAgentVersion by describing a distinct action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reverting an agent to a previous state, but it does not explicitly state when to use it versus alternatives such as diffAgentVersion or createAgentVersion. No exclusions or when-not guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the destructiveHint annotation already signals a mutating operation, the description adds context about the refund being calculated at the child's current rate and matching the original charge, which explains the absence of a rate parameter. This goes beyond the annotation to clarify expected 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?
The description is three concise sentences, front-loaded with the main action. Every sentence provides useful information: what it does, how the calculation works, and a usage tip. No filler or 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?
Given the destructive nature and the presence of sibling tools (transferCreditsToChild, calculateCreditOperation), the description adequately covers the necessary context: it states the operation, explains the rate behavior, and references the calculate endpoint. The lack of an output schema is acceptable, and the description does not need to explain return values.
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 both parameters (from_organization_id and minutes), so the schema carries the burden. The description adds a note that no rate is passed, which is helpful but not essential given the schema's completeness.
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 action ('take back unused minutes') and the resource context (from child organization to reseller balance). It effectively distinguishes itself from sibling tool transferCreditsToChild by indicating the reverse direction, making the 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?
The description provides explicit guidance to use the calculate endpoint first to preview the refund, which is a valuable usage instruction. It does not explicitly state when not to use this tool, but the clear context and mention of the preview step are sufficient for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read/write and destructiveness. The description adds value by clarifying the reseller scoping and the ability to remove the expiry (via null). It doesn't contradict 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 two concise sentences plus a tag, front-loaded with the primary action. No wasted words; the key business rule is included.
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 mutation with one nested object and no output schema, the description covers the main action and a critical constraint. It lacks error/response details, but given the simplicity and annotation coverage, it's adequate.
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 schema has 100% parameter coverage, including descriptions for user_id and expiry_date (format and null semantics). The description reinforces the action but doesn't add new parameter-level details, 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 'Set or remove the expiry date on a child user', using a specific verb and resource. The reseller context distinguishes it from other user-management 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 provides a clear precondition ('must belong to a child organization of your reseller'), which tells the agent when this tool is applicable. It doesn't explicitly mention alternatives, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that credits are immediately deducted from the reseller balance on success, which goes beyond the annotation readOnlyHint=false. Also notes the direct-child constraint, giving important behavioral context. No contradiction with annotations since this is a write operation.
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 with the action front-loaded in the first sentence. Subsequent sentences add essential constraints and prerequisite without 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?
Covers purpose, side effect, and prerequisite, and points to the calculate endpoint. With the nested schema fully documented and annotations providing safety profile, description is complete enough for selecting and invoking the tool, though return-value details are absent.
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 each parameter (to_organization_id, minutes, cost_per_min) already described in the input schema. The tool description does not add new param details, 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 'Transfer minutes from the reseller balance to a child organization' with a specific verb and resource, and distinguishes itself from sibling tools like revertCreditsFromChild and calculateCreditOperation by focusing on the actual transfer action.
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 instructs to 'Use the calculate endpoint first to preview the cost', pairing with the calculateCreditOperation sibling. Also states the prerequisite that the target must be a direct child. Does not explicitly mention when not to use, but provides adequate contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavior beyond the annotations by explaining that this is a partial/patch-like update and by flagging voicemail detection as an access-gated feature that requires account-level enablement. It does not contradict the annotations and gives the agent an important prerequisite to consider.
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 short, front-loaded, and contains no filler: one sentence covers the action and partial-update semantics, and one callout covers the voicemail access requirement. Every part is useful for invoking the tool correctly.
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 description covers the overall semantics and the most important prerequisite despite the tool being large and nested. Because the schema is detailed and covers all parameters, the lack of an output schema description is not a major blocker, though an explicit return-value hint would have improved full 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 already provides detailed per-field descriptions and full parameter coverage. The tool description contributes a general partial-update rule, but it does not add new parameter-level semantics beyond what the schema already documents, so the baseline score 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 clearly starts with 'Update an existing agent', naming both the action and the target resource. It also scopes the behavior with 'Send only the fields you want to change', which differentiates it from createAgent, getAgent, and deleteAgent.
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 provides clear usage context: use this tool when modifying an existing agent, and only include the fields that need changing. It does not explicitly name alternatives or state when not to use it, so it falls short of the most explicit possible guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description reinforces this by stating 'without moving any credits.' It further adds behavioral context by warning that 'The response shape differs between forward transfers and reverts,' which is not present in annotations. The mention of examples is somewhat vague but still provides additional guidance beyond the structured data.
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, four sentences, with no redundant phrasing. It front-loads the core purpose in the first sentence, then provides usage guidance and a caveat. Every sentence contributes meaningful information; 'See the examples' is brief and acceptable. This is appropriately concise and well-structured.
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 tool has no output schema, so the description carries the burden of explaining return behavior. It does state that the response shape differs between forward transfers and reverts but does not describe what the response contains or how it differs. Pointing to examples is not a substitute for concrete detail in the description. For a preview tool, more completeness about the returned data would be expected.
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 schema fully documents every parameter (minutes, is_revert, cost_per_min, child_organization_id). The description does not add any parameter-specific semantics beyond what the schema already provides—it only mentions general operation types and response shape. This meets the baseline but does not exceed it.
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 identifies the tool as a preview action ('Preview the cost of a transfer or revert without moving any credits'), which explicitly distinguishes it from the actual transfer/revert operations. It uses a specific verb ('preview') and resource ('credit operation'), making its purpose unmistakable relative to sibling tools like transferCreditsToChild and revertCreditsFromChild.
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 confirm amounts before calling the transfer or revert endpoints.' This names the alternative operations and sets a clear precondition, effectively guiding the agent to select this tool for cost estimation rather than execution. Though it doesn't cite exact sibling tool names, it refers unambiguously to transfer and revert endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true and readOnlyHint=false, covering the mutation/safety profile. The description adds meaningful behavioral context beyond that, such as 'A dynamic campaign stays alive waiting for contacts instead of completing when its queue drains' and the three execution modes (immediate, scheduled, auto-retry). It does not contradict 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: it front-loads the core action, then uses bold headers and bullet-like paragraphs for static/dynamic distinction. Every sentence earns its place, and the 'Tags: Bulk calls' line at the end is the only minor extraneous element.
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 description covers the key decision (static vs. dynamic) and the dynamic campaign's lifecycle behavior, while the rich input schema handles parameter details. There is no output schema, but for a create tool the missing return-value info is acceptable. It doesn't mention scheduling prerequisites, but the schema covers those 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?
Schema description coverage is 100% with detailed per-parameter descriptions, so the baseline is 3. The description adds conceptual value by tying is_dynamic to contact_list optionality and the webhook, and clearly explaining the two campaign categories—useful for selecting the right parameter combinations beyond what schema descriptions individually provide.
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+resource statement, 'Create a new bulk-call campaign,' and then immediately distinguishes static vs. dynamic campaign types. This differentiates it clearly from sibling tools like fetchBulkCalls, cancelBulkCall, and getBulkCall, which operate on existing campaigns.
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 provides clear context on when to use static vs. dynamic campaigns (e.g., dynamic for real-time ingestion via webhook, static as default), which helps the agent decide which parameters to set. It does not explicitly name alternative tools or state 'use this instead of X,' so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations state readOnlyHint=false and destructiveHint=false, but the description goes further by explaining the pool mechanics. It discloses that increasing the limit may fail if insufficient slots exist, and decreasing returns slots immediately. This adds meaningful behavioral detail beyond the annotations, with no contradictions.
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 concise sentences, each carrying useful information. The first sentence states the purpose, the second explains the slot source, and the third and fourth describe increase/decrease effects. 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?
The tool has no output schema, but the description adequately explains the operation's behavior, effects, failure condition, and reseller context. It does not describe the return value, but for a mutating setter this is a minor gap. The schema covers parameters fully, so overall completeness is strong.
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 covers both parameters, each with clear descriptions (child_organization_id and new_limit with type and constraints). The description adds the concept of 'delta' and slot deduction/return, but does not elaborate on parameter syntax. Schema coverage is 100%, 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 begins with a clear verb+resource: 'Set the maximum number of simultaneous calls a child organization can run.' It uniquely identifies the tool's function among siblings, especially with the reseller context and detailed behavioral explanation.
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: slots come from the reseller's shared pool, increasing deducts from the pool, decreasing returns. This implies when to use (anytime a reseller needs to adjust child concurrency) and why, but it does not explicitly contrast with alternatives. No other sibling tool does this, so exclusion is not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses important behavioral traits: it performs a partial update (only passed flags change) and silently ignores out-of-permission flags. These behaviors are not captured in annotations and are essential for correct invocation, making the description highly transparent.
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 short sentences, starts with the primary purpose, and immediately provides the two key behavioral nuances. Every sentence adds value, with no fluff or repetition. The (Tags: Reseller) note is a useful additional context.
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 description is complete for a mutation tool with a rich schema and no output schema: it covers the action, partial-update semantics, permission behavior, and target resource. It does not mention edge cases like invalid user_id or clearing all flags, but these are not essential given the schema's detail. A slight gap is the lack of any statement about return values or errors, but the silent-ignore behavior partially covers error handling.
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 input schema already explains the requestBody, user_id, and the dashboard_menu_access flags. The main description restates the partial-update semantics already present in the schema, adding no new meaning beyond the structured fields. 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 verb 'Enable or disable' and the resource 'dashboard menu access flags for a child user'. This is specific and distinguishes it from sibling tools like setUserExpiry (expiry) and setChildConcurrency (concurrency), both of which target different resource aspects.
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 usage context: partial updates ('Only the flags you pass are changed') and permission constraints ('Flags outside your reseller's permissions are silently ignored'). It lacks explicit alternatives, but no direct alternative exists among siblings, so the when-to-use is clear from the first sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: it explains no audio starts on creation, details the single-use/expiring ws_url, and clarifies server-side responsibility. Annotations indicate mutation but not destructive, which aligns. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with two focused paragraphs and a tag. First paragraph defines purpose and context; second gives usage instructions. The tag 'Tags: Sessions' is minor extra. Could be slightly tighter, but effective and 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?
No output schema, but description explains the return value (ws_url) and its properties (single-use, expires). Covers the two-step flow and security constraints. Minor lack of error handling details, but adequate for a simple session creation 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%, so baseline is 3. The description does not elaborate on parameter details beyond the schema; it mentions agent_id indirectly but adds no new semantic information. The custom_variables description in schema already covers tampering risk, so description adds marginal value.
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 'Create a voice Session: a short-lived, single-conversation reservation that lets a client hold a live voice chat with your agent.' It uses specific verbs and resources, and the sibling tools list shows no overlap with voice sessions, so it distinguishes well.
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 step context: 'This is step 1 of 2.' Provides clear when-to-use guidance ('Call this endpoint from your server... return only the ws_url to your client'), and strong exclusions ('The API key must never reach the browser'). It also references alternative resource for the next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds useful behavioral context: pagination, reverse-chronological ordering, and inclusive date filters. These details go beyond the structured annotations, providing a clear picture of what to expect.
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, front-loaded with the core purpose, and packed with specific details (paginated, reverse-chronological, inclusive dates) without any redundant fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, complete input schema, and readOnlyHint annotation, the description fully covers the tool's behavior and return value. It explains pagination, ordering, and date filtering, which is sufficient for a historical log retrieval tool. No output schema exists, but the description describes 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 baseline is 3. The description adds meaning by clarifying that date filters are inclusive, which is not fully explicit in the schema (e.g., date_from says 'from this date' but not 'inclusive'). This extra semantic clarification justifies a score above baseline.
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 returns a paginated history of credit transfers and reverts for the reseller account, with specific behavioral details like reverse-chronological order and inclusive date filters. This distinguishes it from sibling tools like transferCreditsToChild or listCallLogs.
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 usage: when you need credit transfer history. It clearly scopes to reseller account credit logs but does not explicitly mention alternatives or exclusions. Context is clear though no direct comparison with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds value by specifying the exact return fields (balance, cost-per-minute, concurrency limit, dashboard access flags) and the permission scoping ('scoped to your reseller's permissions'). This goes beyond just labeling it read-only.
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 and front-loaded with the action and resource. It uses two informative sentences plus a 'Tags: Reseller' note, with no wasted words. 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?
Despite having no output schema, the description comprehensively explains what the tool returns and the scope. It covers all key aspects an agent would need to decide to call it, including the specific data fields and permission context. No significant gaps remain.
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 empty input schema fully covers parameter documentation. The description adds no parameter info because none exists; the baseline of 4 for 0-parameter tools 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 clearly states the tool 'List all child organizations and their users' with a specific verb and resource, and details the returned data (balance, rate, concurrency, access flags). It distinguishes itself from sibling tools like listAgents and listPhoneNumbers by focusing on reseller child organizations.
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 clearly implies the tool is for reseller-level operations, specifying 'under the reseller account' and 'scoped to your reseller's permissions'. However, it does not explicitly mention when not to use it or name alternative tools for other listing scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![omnidim-mcp-server MCP server](https://glama.ai/mcp/servers/Omnidim/omnidim-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Omnidim/omnidim-mcp-server)

Score Badge

Copy to your README.md:

[![omnidim-mcp-server MCP server](https://glama.ai/mcp/servers/Omnidim/omnidim-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Omnidim/omnidim-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Omnidim/omnidim-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server