VoIPbin MCP Server
OfficialServer Quality Checklist
Latest release: v0.1.1
- Disambiguation4/5
Each tool targets a distinct resource (numbers, contacts, flows, calls, messages, etc.) with clear naming, and the resource-specific verbs (list/get/create/update/delete) make purposes clear. The only minor ambiguity is the large volume of similar list/get pairs, but the resource names disambiguate well.
Naming Consistency4/5Tool names consistently follow a verb_noun pattern in lowercase snake_case (e.g., list_contacts, create_flow, send_message). The minor deviation is 'activeflows' instead of 'active_flows' (and 'get_activeflow', 'stop_activeflow'), but overall the naming is highly predictable.
Tool Count1/5With 52 tools, the server is extremely large and unwieldy for an MCP interface. Even for a comprehensive VoIP platform, this far exceeds typical MCP scoping and would overwhelm agents, making tool selection prone to error.
Completeness2/5Many resources (queues, routes, tags, extensions, billings, numbers, agents) are read-only with no create/update/delete, leaving significant lifecycle gaps. Core resources like flows, contacts, and campaigns have full CRUD, but the surface feels incomplete for an account management server.
Average 3.7/5 across 52 of 52 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Get details' which is a restatement of the name and does not clarify read-only nature, side effects, permission requirements, or error behavior. No additional context is provided beyond the operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence plus a compact Args block. There is no fluff or redundancy; every word adds value. The structure is clear and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is minimally adequate, but it lacks usage guidelines and behavioral details. The agent knows what the tool does but might not fully understand when to invoke it or what to expect beyond the schema. The description could be more complete without adding much length.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds semantic clarity by stating route_id is 'The UUID of the route', which is more informative than the schema's 'Route Id'. However, this is minimal compensation for 0% schema coverage. It does not explain optionality or any constraints beyond being a UUID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific route', which identifies the resource (route) and the operation (get). It is distinct from list_routes through the word 'specific', though it does not explicitly name alternatives. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like list_routes or other get_* tools. It does not mention prerequisites, typical scenarios, or when not to use it. The only implicit hint is the requirement for a route_id.
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?
No annotations are provided, so the description must convey behavior. It only says 'update' and takes a fields dictionary, but does not disclose whether it is a partial update, validation rules, side effects, or required permissions. This is minimal and leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with a clear Args block, no redundant text. It is front-loaded with the action and then lists parameters. While it is under-specified, it is concise and free of fluff, earning a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and nested objects, yet the description omits important context such as whether the update replaces or merges fields, the range of valid field keys, or any effects on the campaign. With no annotations to fill the gap, the description is incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It does name both parameters and clarifies that fields is a dictionary with example keys, adding value over the schema. However, it does not enumerate valid field names or describe the nested structure, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a campaign' with a verb and resource, and the Args list mentions specific field types (name, detail, actions). However, it does not differentiate from other update tools like update_flow or update_contact, though the resource is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_campaign, get_campaign, or delete_campaign. No context about prerequisites, typical scenarios, or why to choose this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only says 'Delete a campaign' without indicating irreversibility, permissions, side effects, or return value. This is a tautology of the tool name and provides no 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with the action. The Args block is minimal but structured. No unnecessary words are used, though it could be enhanced without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no other context, the description is notably incomplete. It fails to communicate that deletion is likely permanent or what consequences may follow. While an output schema exists and could explain return values, the description itself lacks essential context for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema only shows campaign_id as a string with title 'Campaign Id', the description adds meaningful semantics by stating it is 'The UUID of the campaign.' This clarifies the format and purpose beyond the schema, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a campaign' with a specific verb and resource. This distinguishes it from sibling tools like delete_contact and delete_flow, as the resource type is explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description simply restates the action without any context about prerequisites, conditions, or exclusions. There is no mention of when not to use it or which sibling might be preferable.
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?
With no annotations provided, the description carries the full transparency burden. It only states the basic purpose and the message_id argument, without disclosing error behavior, return format, authentication needs, or any side effects. This is a minimal disclosure for a read 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and one for the argument. There is no redundant or irrelevant content, and the structure is clear for a single-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with an output schema and a single parameter, the description is functionally sufficient. However, it lacks any mention of related tools (e.g., list_messages) or the context in which this tool should be invoked, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that message_id is 'The UUID of the message', which provides semantic meaning beyond the schema's 'Message Id' title. However, it does not provide format validation, examples, or clarify if the UUID must be an existing message, leaving marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific message' provides a specific verb and resource, distinguishing it from list_messages and send_message. It clearly states the action of retrieving one message, though it does not detail what 'details' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It only implies selection of a single message via 'specific', but does not mention sibling tools like list_messages for enumerating messages, nor any exclusions or prerequisites.
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?
With no annotations available, the description carries the full burden for behavioral disclosure. It only states 'Get details,' which implies a read operation, but doesn't disclose output format, error behavior, permissions, or any side effects. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence and a brief parameter note. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 an output schema, the description is minimally sufficient. It lacks usage context and behavioral details, but the core invocation intent is clear. More context about similar tools or edge cases would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for number_id beyond 'string,' but the description adds meaning by stating 'The UUID of the number.' This clarifies the expected value, compensating for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific phone number' with a specific verb and resource. It distinguishes itself from list_numbers (listing all numbers) and other get_* siblings, though it doesn't 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 Guidelines2/5Does 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. It only implies usage when you have a number_id, but there is no explicit context, prerequisites, 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?
Given the lack of annotations, the description carries the full burden but does not disclose side effects, reversibility, or prerequisites. For a mutating operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise and front-loaded, with a single declarative sentence plus a minimal parameter doc. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits behavioral context (e.g., what happens to the flow, whether it's safe, if it can be restarted). The presence of an output schema reduces the need to describe return values, but side effects are still undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the semantic detail that activeflow_id is a UUID, which is not present in the schema. However, it doesn't explain how to obtain the value or any constraints beyond the basic identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and the resource ('a running active flow'), distinguishing it from sibling tools like get_activeflow or delete_flow. The verb is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as delete_flow or hangup_call. The single sentence implies usage but lacks explicit context, prerequisites, 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?
With no annotations, the description must disclose behavioral traits, but it only restates the action and argument. It does not mention idempotency, error behavior, cascading effects, or permission requirements, which are critical for a delete 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a two-sentence action statement followed by a clear Args block. It is front-loaded and contains no unnecessary words, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description covers the core action and argument. However, it lacks usage guidance and behavioral details that would help an agent use it correctly, such as whether the flow must exist or if deletion is permanent. The presence of an output schema does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that flow_id is 'The UUID of the flow to delete', specifying the format as UUID, which is a slight improvement over the schema's bare 'string' type. However, it largely restates the parameter's purpose without additional constraints or context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a flow' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_flow, update_flow, and get_flow. It precisely states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives or about preconditions. It does not mention whether the flow must exist or that deletion is irreversible, leaving the invocation context unclear.
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?
Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It only states the action and does not mention side effects, permissions, error behavior, or return format, leaving significant gaps for a tool that could potentially fail or behave unexpectedly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of a single sentence and an Args block with one parameter. Every word serves a purpose, and the structure is clean and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description covers the essential purpose and parameter semantics. It does not need to explain return values due to the output schema, but lacks usage context and alternative tool mentions that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description compensates by explaining activeflow_id as 'The UUID of the active flow.' This adds useful semantic information beyond the schema's plain string type, though it could be even more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Get details of a running active flow.' This distinguishes it from related tools like get_flow and list_activeflows by focusing on 'active' flows, though it doesn't 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_flow or list_activeflows. The description lacks any contextual direction for tool selection, making it inadequate for an agent deciding between sibling tools.
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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It merely states 'get details', which is implicit in the tool name, and does not disclose behavior on missing records, authorization requirements, or any side effects beyond the read-only nature of 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a clear one-sentence purpose followed by a single parameter definition. Every word contributes to understanding the tool, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A simple get tool with an output schema, so return values are covered. Yet the description lacks usage context (when to use vs list_billings) and error/edge-case behavior. It is minimally viable but leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines billing_id as a string with no description, so the description's addition of 'The UUID of the billing record' adds semantic meaning. However, this is minimal and does not explain why the parameter is needed or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a specific resource ('details of a specific billing record'), distinguishing it from the sibling tool 'list_billings'. This clearly defines 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/5Does 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 list_billings. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely from the name.
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?
With no annotations, the description must disclose behavioral traits but only states the obvious 'create' action. It omits permission requirements, idempotency, error behavior, or side effects. The format examples for phone/email are input-related, not 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose line, format examples, and an Args list. It is appropriately sized for an 8-parameter tool and front-loads the core action. The Args section adds some redundancy with schema titles but serves as a useful quick reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's purpose and parameter semantics are well covered, which is adequate for a basic create operation. However, the lack of usage guidelines and behavioral transparency creates gaps. The presence of an output schema likely covers return values, so the description is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by enumerating all eight parameters and giving explicit format examples for the complex phone_numbers and emails structures. Simple fields like first_name are briefly defined, adding clarity beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new contact,' which uses a specific verb and resource, clearly distinguishing it from sibling tools like list_contacts, update_contact, and delete_contact. There is no ambiguity about the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 update_contact. It does not mention scenarios, prerequisites, or duplicate handling, leaving the agent without decision context.
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?
No annotations are provided, so the description carries the full burden. It only says 'Get details,' which is the operation itself, with no mention of side effects, error handling, permissions, or response behavior. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and front-loaded: one sentence for purpose, one line for the parameter. No wasted words, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool with an output schema, the description is mostly adequate. However, it lacks any context about missing IDs, permissions, or potential errors, which would be helpful for an agent to handle edge cases. It is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for ai_id by specifying it is 'The UUID of the AI agent,' which is more informative than the schema's generic string type. With only one parameter and 0% schema coverage, this sufficiently clarifies the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves details for a specific AI voice agent, using the verb 'Get' and identifying the resource. It is unambiguous, though it doesn't explicitly differentiate between sibling tools like get_agent or list_ais.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when you need details for one AI voice agent by its UUID. No explicit when-to-use, alternatives, or exclusions are provided, which is acceptable for a simple getter but leaves some ambiguity.
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 are not provided, so the description carries full responsibility for behavioral disclosure. It only says 'Get details', with no mention of side effects, error behavior (e.g., 404 on not found), authentication, or rate limits. For a getter, the lack of any behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. It includes a simple Args section with the parameter. Every word earns its place, but it may be too terse, lacking any elaboration for the parameter. Still, it is well-structured and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple getter with an output schema (not shown but present), the description is minimally sufficient for invocation. However, it does not provide guidance on when to use it versus list_conversations, nor any behavioral notes. It is adequate for a basic tool but not fully complete in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string type for conversation_id, and the description adds that it is a 'UUID of the conversation', giving some meaning beyond the schema. However, it doesn't explain the format beyond UUID or how to obtain the ID, nor any constraints. With 0% schema coverage, the description compensates minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific conversation', which is a specific verb ('Get details') and resource ('specific conversation'). It distinguishes itself from sibling tools like list_conversations (listing all) and get_message (messages vs conversations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: when you have a conversation_id and need its details. However, there is no explicit guidance about when to use this over alternatives, nor any exclusions or prerequisites. The parameter name makes the use case obvious, but the description offers no direct comparison.
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?
With no annotations provided, the description must disclose behavioral traits. It only states 'Get details' with no mention of side effects, error behavior (e.g., what happens if the email_id is not found), authentication requirements, or rate limits. While the operation is inherently read-only, this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no superfluous wording. It fits the minimal nature of the tool, though it could include an additional sentence about error cases without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the primary purpose and argument. However, the lack of annotations means the description should also state read-only behavior and potential errors, which it does not, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the type 'string' for email_id, and the description adds 'The UUID of the email,' clarifying the format and meaning. This partially compensates for the 0% schema description coverage, but it lacks examples, constraints, or referring context (e.g., how to obtain a list of email IDs).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get details of a specific email'), clearly distinguishing it from sibling tools like list_emails (which lists multiple) and send_email (which creates an outgoing email). The word 'specific' plus the email_id parameter makes the singular retrieval purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the description suggests this tool is for when you need details of one specific email by ID. However, it does not explicitly contrast with list_emails or mention any exclusions, such as not being able to fetch emails from threads or requiring certain permissions.
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?
No annotations provided, so the description is the sole source of behavioral context. It only lists parameters and does not describe what happens upon creation, return values, side effects, or any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured, with a one-sentence summary followed by a clear argument list. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description adequately explains the parameters and the output schema is provided, it lacks usage context (when to use), behavioral details (response/return, side effects), and any constraints beyond what's in the schema. This makes it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful explanations for each parameter, including the execution context of pre_flow_id and post_flow_id, and clarifies the timeout unit and default. This goes beyond the schema, which only has property names without descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new conference' with a specific verb and resource. This distinguishes it from sibling tools like list_conferences, get_conference, and delete_conference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not mention prerequisites, exclusions, or alternative tools for similar operations.
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?
No annotations are provided, and the description simply restates the operation without disclosing consequences such as permanence, reversibility, or permissions. 'Delete' implies destructiveness, but the description adds no behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and immediately explaining the sole parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete operation, the description is minimally viable. However, it lacks any detail about side effects, error cases, or requirements, making it less complete than ideal for an unattended agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only 'string' and 'Conference Id', but the description clarifies that conference_id is the UUID of the conference to delete, adding meaningful type and role information. This compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Delete') and the specific resource ('conference'), distinguishing it from sibling delete tools like delete_contact and delete_flow. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or alternatives. The description does not mention anything like 'permanently removes' or 'use get_conference first to verify existence.'
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only repeats the tool's name and does not mention consequences such as permanence, cascading effects, or required permissions, leaving the agent unaware of the destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence and a clear 'Args' section. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool, the description is functional and provides the necessary parameter information. However, it lacks behavioral warnings about irreversibility or error handling. The presence of an output schema reduces the need to explain return values, but the destructive nature should be highlighted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that contact_id is the UUID of the contact to delete, which adds meaning beyond the schema's bare type declaration. This is especially valuable given the schema description coverage is 0%. However, it is minimal and could be more explicit about format restrictions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Delete a contact.' This distinguishes it from sibling tools like create_contact, update_contact, and get_contact, which have different verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, any prerequisites, or alternatives. It simply states the action without offering context about the deletion scenario or distinguishing between similar delete tools.
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?
With no annotations, the description carries full behavioral disclosure burden. It states only 'Get details' but does not mention side-effect-free behavior, error conditions, or required permissions. The ambiguity of 'details' adds no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear front-loaded verb and a structured Args block. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered. However, the description lacks usage context (e.g., when to use vs alternatives) and does not elaborate on 'details', leaving gaps that are more than expected for a simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only 'type: string' with no description. The Args section clarifies agent_id is 'The UUID of the agent', adding critical format and meaning beyond the schema. This compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific agent' uses a specific verb ('Get') and resource ('agent'), clearly distinguishing it from sibling tools like list_agents. It leaves no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of using list_agents to find agent IDs or any exclusions, leaving the agent without clear context for tool selection.
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?
No annotations are present, so the description must carry the full burden. It only says 'get details' without disclosing behavior such as error handling, not-found responses, permissions, or output format. The description is minimal and does not reveal any non-obvious traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the main purpose. The Args section is concise and adds the UUID detail without redundancy. Every sentence earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema present, so return values need not be explained. However, the lack of usage guidelines and behavioral transparency creates gaps, making the description only marginally adequate for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a type and title for extension_id with 0% description coverage. The description adds that it is 'The UUID of the extension,' giving semantic meaning beyond the schema. This compensates for the gap, though it doesn't elaborate on accepted UUID formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific extension,' identifying the action (get) and resource (extension). The word 'specific' distinguishes it from the sibling tool list_extensions, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 list_extensions. There is no mention of context, prerequisites, or scenarios where this tool is appropriate, leaving the agent without decision support.
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?
Since no annotations are provided, the description carries the behavioral disclosure burden. It does mention pagination behavior (page_size, page_token), indicating that results are paged and that page_token comes from a previous response. However, it does not disclose ordering, filtering, or whether deleted or inactive agents are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single statement of purpose followed by a compact parameter list. Every sentence earns its place and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional pagination parameters and an output schema, the description covers the essentials. It explains pagination and the purpose, though it could be more complete with a note about iterating pages or clarifying the difference from 'list_agents'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides parameter names and defaults (0% coverage), so the description must compensate. It clearly explains page_size ('Number of results per page') and page_token ('Pagination cursor from a previous response'), adding meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all AI voice agents') with a specific scope ('in your VoIPbin account'). It is specific but does not differentiate from the sibling tool 'list_agents', which could be confusing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives like 'list_agents'. There are no exclusions, prerequisites, or context about when this listing is appropriate.
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?
With no annotations, the description carries the burden of behavioral disclosure. It does mention pagination via the args (page_size, page_token), which hints at the response being paged. However, it does not explicitly state whether the operation is read-only, how 'all emails' interacts with pagination, or any other behavioral characteristics like ordering or 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose, followed by a clear Args section. Every sentence/line earns its place with no fluff or repetition of schema fields beyond what is necessary for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 optional params, output schema exists) and adequate parameter documentation, the description covers the essentials. However, it lacks usage guidelines and any broader context about when to choose this over sibling list tools, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema description coverage is 0%, the description fully compensates by explaining both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response.' This adds meaningful semantics beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all emails in your VoIPbin account.' with a specific verb (list) and resource (emails). It is distinct from sibling tools like list_messages or get_email by resource type, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 list_messages or get_email. The description simply defines the action without context or exclusions, leaving the agent to infer usage from the name alone.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Send an email.' without mentioning any side effects (e.g., message sent, record created), delivery behavior, authentication requirements, or rate limits. This is a significant gap for a tool with write/side-effect 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single purpose line followed by a clear arg breakdown. Every sentence is informative, and it is front-loaded with the main action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (3 params, all documented) and an output schema exists, the description covers parameter semantics well. However, it lacks usage context, behavioral side effects, and any distinction from similar tools, making it minimally complete but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly defines each parameter: destination_email (recipient), subject (subject line), and content (body with HTML/plain text note). Since the schema lacks descriptions (0% coverage), this fully compensates and adds meaningful context beyond the schema's basic type/title information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send an email.' which is a specific verb+resource combination. It distinguishes itself from siblings like send_message (which is likely for messages) and list_emails/get_email (which are read 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/5Does 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 send_message for different message types. There are no exclusions, prerequisites, or alternative tool references.
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?
With no annotations, the description must disclose side effects, but it does not mention mutation, permissions, asynchronous behavior, or failure modes. The only behavioral hint is that flow_id executes on connect, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: one-sentence purpose followed by a clear parameter list. Each line is informative with no redundancy, and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all five parameters with types and examples, and since an output schema exists, return values need not be explained. However, it lacks context on call lifecycle or how this differs from other call operations, leaving some room for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fully compensates by explaining each parameter, listing allowed types (tel, sip, agent), providing examples for source_target and destination_target, and clarifying flow_id as optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new outbound call,' using a specific verb and resource. It distinguishes itself from sibling tools like hangup_call and get_call, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, contexts, or exclusions; the description simply documents parameters.
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 are absent, so the description must disclose behavioral traits. It only says 'Get details' and provides no information about read-only behavior, error handling, permissions, or response format. For a mutation-ambiguous tool this would be a serious gap; for a 'get' tool it is still thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, with a clear first line and a simple parameter listing. No redundant text or fluff, and it is immediately readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so the description need not explain return values. However, it provides no context about error conditions, suggested prerequisites, or differences from related get_* tools. For a simple one-parameter getter, this is adequate but leaves room for more helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly identifies campaign_id as a UUID, adding semantic meaning beyond the schema's generic string type. This helps the agent format the parameter correctly. Despite the schema's 0% description coverage, the description compensates for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific campaign' with a specific verb and resource. It distinguishes itself from list_campaigns by targeting a single campaign, and from create/update/delete by being a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the name and the campaign_id argument, but there is no explicit guidance on when to use this tool versus alternatives like list_campaigns or get_* tools. No exclusions or conditional use cases are mentioned.
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?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get details' without addressing error behavior (e.g., not found), permissions, or confirming it is a read-only operation. This leaves the agent with insufficient safety or edge-case information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with an Args block. It front-loads the main action and adds no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, an output schema, and a straightforward purpose, so the description covers the core function. However, it omits guidance on error handling or how to obtain the conference ID (e.g., via list_conferences), leaving an agent to infer important workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes conference_id as a string, but the description's Args block adds meaningful semantics by specifying it is a UUID. This helps the agent understand the expected format and value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'details of a specific conference.' This distinguishes it from sibling tools like list_conferences (which retrieves multiple) and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving a single conference by ID, but it does not explicitly state when to use it versus list_conferences or provide any exclusion criteria. The context is clear but not fully articulated.
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 verb 'Get' implies a read-only operation, which is a basic behavioral trait, but the description does not disclose error behavior, required permissions, or the exact content of 'details'. With no annotations, the description carries full burden and could be more explicit about side effects and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the purpose and a compact Args section for the single parameter. Every word earns its place, and it is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are covered, but the description lacks usage context (e.g., when to use vs list_contacts) and doesn't mention error handling. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the property name and type, while the description adds that contact_id is 'The UUID of the contact', clarifying the format and purpose. This goes beyond the schema's minimal info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'contact', clarifying it retrieves details for a specific contact by UUID. This distinguishes it from list_contacts, delete_contact, and other contact 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like list_contacts or get_contact variants. No explicit context, prerequisites, or exclusions are provided.
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?
No annotations are provided, so the description carries full behavioral disclosure burden. It states the action ('hang up') but does not reveal side effects such as irreversibility, required permissions, or what happens if the call is already hung up. For a mutating operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with two clear sentences, front-loading the purpose and briefly documenting the parameter. No unnecessary words, and the Args format is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description is nearly adequate. However, the lack of behavioral details (e.g., error conditions, prerequisites) and absence of annotations reduce completeness. It would benefit from mentioning that the call must be active.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description compensates by explaining that call_id is 'The UUID of the call to hang up.' This adds meaningful context beyond the schema's generic title 'Call Id', although it does not specify where to obtain the UUID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hang up an active call' uses a clear verb and object, distinguishing it from sibling tools like get_call or create_call. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an active call needs to be terminated, but it does not explicitly mention when not to use it or mention alternatives. It lacks guidance on prerequisites like whether the call must be owned by the user or in a certain state.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not explicitly state that this is a read-only operation, nor does it describe pagination behavior (beyond parameter names), sorting, or whether archived/inactive campaigns are included. The description is minimal and relies on the implied safety of a 'list' 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the purpose, followed by a brief context sentence and a straightforward Args list. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and parameters, and an output schema exists so return values are presumably documented. However, it lacks explicit details about pagination flow (e.g., how to retrieve subsequent pages), filtering behavior, or any edge cases like empty results or permission requirements. For a simple list tool this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that explains both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response.' This adds meaning beyond the bare schema, which only provides types and defaults, and is especially valuable given 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all outbound campaigns' with a specific verb and resource, and adds context about what campaigns are (automate outbound calling, SMS, or email). This distinguishes it from sibling tools like list_calls or list_flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all campaigns but provides no explicit guidance on when to choose this over related tools (e.g., get_campaign for a single campaign). No alternatives or exclusions are mentioned, leaving the choice based on the tool name 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?
There are no annotations, so the description carries the full burden. It does add a useful behavioral detail—'including its full action sequence'—which indicates the return content. However, it does not disclose error handling, authentication requirements, or any potential side effects, even though reads are typically safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a short purpose statement and a single parameter definition. Every sentence adds value, and the Args formatting is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 an output schema, the description is mostly complete. It tells the user what the tool does and what it returns. However, it lacks guidance on when to choose this over related getters or how to handle not-found cases, leaving a minor gap in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section clarifying that flow_id is 'The UUID of the flow', which adds semantic meaning beyond the schema's generic 'string' type. With only one parameter, this provides sufficient context, though it could be more detailed about the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a flow by its ID, including its full action sequence' clearly states the specific action (get), the resource (flow), and the key differentiator (by ID, full action sequence). It distinguishes itself from sibling tools like list_flows and get_activeflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention that list_flows should be used to enumerate flows, or that get_activeflow is for active flows. The context is implied by the word 'get', but no explicit when/why is provided.
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?
No annotations are provided, so the description carries the full burden. It only states the action and parameter without disclosing behavioral details such as read-only nature, error handling, or prerequisites. The tool name implies a read operation, but the description adds no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, with a clear purpose statement followed by a single parameter explanation. Every word earns its place, and the structure is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get operation, the description is adequate. It provides essential information about the tool's purpose and parameter. Since an output schema exists, return value details are not needed. However, it lacks guidance on related operations or error scenarios, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents queue_id as 'The UUID of the queue', adding semantic meaning beyond the schema's plain string type. With 0% schema description coverage, this compensation is valuable and clarifies the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific queue', which identifies the action (get) and resource (queue details). It distinguishes from sibling list_queues by specifying 'specific queue' rather than listing all queues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single queue identified by queue_id but does not explicitly mention when to use this tool over alternatives like list_queues. It lacks explicit exclusions or alternative tool references.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It clearly implies a read-only operation via 'Get details', but does not state what happens if the tag does not exist, whether authentication is required, or any side effects. For a simple get tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two sentences that cover the purpose and the sole parameter. It is front-loaded with the main verb, and the Args section is a standard, clear structure. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is adequate. It does not explain return values, but that is unnecessary with an output schema available. The description could theoretically include usage context, but for a single-resource get, the provided information suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and type (string), with no description. The description adds crucial meaning by stating tag_id is 'The UUID of the tag', clarifying both its format and semantic role. This goes beyond what the schema offers, helping the agent understand what value to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('specific tag'), which distinguishes it from sibling tools like list_tags (listing tags) and other get_* tools. The phrase 'specific tag' implies retrieval by unique identifier, setting expectations for a single-resource read 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, suitable contexts, or mention that for listing tags one should use list_tags. The intent is implicitly conveyed by the tool's naming convention, but there is no direct advisory.
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?
No annotations are provided, so the description carries the burden. It discloses the basic listing behavior and implicitly suggests pagination through the presence of 'page_size' and 'page_token' args, but it does not describe the output format, sorting, authentication requirements, or any potential side effects. This is minimal but acceptable for a simple read-style list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence purpose followed by a clean parameter list. It is front-loaded with the core operation, contains no fluff, and every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list tool, the description covers the essential purpose and parameter semantics. An output schema is available, so return-value details are presumably covered there. However, it lacks usage context and any mention of filters or limits, which would make it more complete for an agent selecting among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's 'Args' section compensates by explaining both parameters: 'Number of results per page (default 10)' and 'Pagination cursor from a previous response'. This adds meaningful context beyond the bare schema types and defaults, though it could be more detailed (e.g., max page size, token format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all billing records in your VoIPbin account', which uses a specific verb and resource, and distinguishes this tool from siblings like 'get_billing' and other 'list_' tools. The scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'get_billing' or other list tools. It does not mention any prerequisites, excluded scenarios, or suggest when pagination is needed, leaving usage decisions entirely to the agent.
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?
With no annotations, the description must disclose behavior. It states the tool lists all contacts and explains the pagination parameters, implying a read-only operation. However, it doesn't explicitly confirm non-destructiveness, mention ordering, or clarify that results are returned in pages despite saying 'all'. Adding a note like 'This is a read-only operation' would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a focused Args block; the main purpose is stated first, and parameter documentation is structured and free of redundancy. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional params and an output schema, and the description covers the pagination semantics adequately. It might benefit from mentioning that the result is a paginated list of contacts and how to iterate, but given the output schema exists and the description is clear about args, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are entirely absent (0% coverage), so the description's Args section provides essential meaning: page_size defines page size with a default, and page_token is explained as a pagination cursor from a previous response. This compensates well for the schema gap, though it could elaborate on how page_token is obtained (e.g., from the response).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('contacts') and scope ('in your VoIPbin account'), distinguishing it from sibling contact tools like get_contact or delete_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose list_contacts over alternatives; it doesn't reference get_contact for single-contact lookup or mention pagination as a reason to use this tool. The description simply states what it does without context.
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?
With no annotations, the description must carry the burden of behavioral disclosure. It mentions pagination via page_size and page_token, which is useful, and implies read-only behavior with 'List'. However, it does not discuss rate limits, sorting, or any side effects beyond what is obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, leading with the main purpose and then clearly listing parameters. Every sentence adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with an output schema present, the description covers the action and both parameters adequately. It lacks explicit mention of the return structure, but that is provided by the output schema. It could mention potential use cases or limitations, but overall it is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for its parameters, so the description compensates by explaining page_size as 'Number of results per page' and page_token as a 'Pagination cursor from a previous response.' This adds meaningful semantic context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List all phone numbers'), clearly distinguishing it from sibling tools like get_number, list_contacts, etc. It also scopes to the user's VoIPbin account, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_number for retrieving a single number. The description implies usage for browsing the full list, but does not explicitly state exclusions or 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the read-only nature ('List all tags') and explains pagination parameters, but lacks details such as authentication requirements, potential rate limits, ordering, or edge cases. The description adds some context but not rich behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear opening sentence, a brief domain note, and an 'Args' section. It avoids unnecessary verbosity and every sentence adds value, though a slightly cleaner separation of purpose and parameters could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of this list tool with only two optional parameters and an existing output schema, the description is largely complete. It covers pagination and the scope of results, and since an output schema exists, it need not describe return values. It lacks only minor details like sorting or filtering options, but these are not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly explains both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response'. This adds meaningful semantics beyond the bare schema types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all tags in your VoIPbin account' with a specific verb and resource, distinguishing it from the sibling 'get_tag' which retrieves a single tag. The additional context that tags can be applied to contacts, calls, and resources further clarifies the tool's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all tags, but it does not explicitly state when to use this tool versus alternatives like 'get_tag'. There are no exclusions or prerequisite conditions mentioned, leaving usage guidance purely 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?
With no annotations, the description carries the transparency burden. It discloses pagination through the page_size and page_token parameters and indicates all conferences are listed, but it does not detail return format, ordering, or potential pagination limits. This is adequate for a simple list operation but not deeply 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a leading purpose sentence followed by a clear args list. Every sentence adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description covers the essential purpose and pagination parameters. It lacks explicit usage alternatives but is otherwise sufficient given the tool's low complexity and available output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response,' adding meaningful context beyond the raw schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all conferences in your VoIPbin account,' using a specific verb and resource. This distinguishes it from sibling tools like get_conference, create_conference, and delete_conference by focusing on the listing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a listing tool but does not explicitly mention when to use it over alternatives like get_conference. There are no exclusions or alternative recommendations, so guidance is only implied by the tool's name and purpose.
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?
No annotations are provided, so the description carries the full burden. It discloses pagination behavior through the Args section (page_size, page_token) and states the scope ('all extensions in your VoIPbin account'). It does not discuss auth, rate limits, or potential side effects, but for a read-only list operation this 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose, followed by a helpful clarification of what an extension is, and then a clean Args block. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple list tool with an output schema present, the description covers purpose, parameter semantics, and pagination. It might optionally mention ordering or max page size, but overall it is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only types and defaults, with 0% description coverage. The description compensates by explaining page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response', adding meaning beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('extensions') with the scope 'in your VoIPbin account'. It additionally clarifies what extensions are ('internal phone lines assigned to agents'), which effectively distinguishes this tool from sibling tools like list_numbers or list_agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this to list all extensions in the account, and the extension definition hints at the concept. However, it does not explicitly state when to prefer this over other list tools or how it relates to get_extension. No exclusions or alternative tools are mentioned.
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?
With no annotations, the description carries the full burden. It discloses pagination behavior via page_size and page_token, and it's read-only by nature. However, it does not mention ordering, filtering, or other potential edge cases, leaving some behavioral details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The args section is minimal, with no filler or redundancy. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with an output schema, the description is largely sufficient. It covers pagination parameters and gives a clear scope. It could add more context about result ordering or typical use cases, but the given information is adequate for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions, so the description fully compensates by explaining page_size as 'Number of results per page' and page_token as 'Pagination cursor from a previous response.' This adds meaning beyond the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action and resource: 'List all SMS messages in your VoIPbin account.' This distinguishes it from sibling tools like list_emails or list_numbers, which target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it lists SMS messages, but it does not explicitly explain when to choose it over alternatives like get_message or list_conversations. It provides no exclusions or comparison context, though the action is straightforward.
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?
With no annotations, the description carries the transparency burden. It discloses that fields is a dictionary and lists valid keys, plus states contact_id is a UUID. However, it does not clarify merge vs. replace semantics, permission requirements, or side effects—only basic update 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-organized: a one-line purpose, a sentence explaining fields, and an Args section. Every sentence 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, the description covers the required parameters and valid field keys, and an output schema exists for return values. However, it lacks details on nested structures like phone_numbers/emails formats, which could trip up an agent. Overall it's mostly complete but with minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides meaningful parameter documentation: contact_id is a UUID and fields is a dictionary with a specified set of valid keys. This adds crucial semantic meaning beyond the bare schema (which only has additionalProperties: true).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing contact,' which is a specific verb+resource pair. It distinguishes from sibling tools like create_contact, delete_contact, and get_contact by focusing on modification of existing records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to update a contact's fields) but does not explicitly contrast with alternatives like create_contact or delete_contact. No 'use this instead of...' guidance is provided, though the context is clear from the 'existing contact' phrasing.
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?
No annotations are provided, so the description carries the burden of disclosure. It adds valuable context by explaining the structure of actions, including the fields (id, next_id, type, option) and listing valid action types. However, it does not disclose side effects (e.g., persistent resource creation), prerequisites, possible validation errors, or whether the operation is reversible, which limits behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but well-structured: it opens with the purpose, then explains the action format, provides an example, and lists arguments. Each sentence contributes to understanding, and the example is especially useful. It is not overly verbose for the complexity of the action structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. It adequately covers the complex actions parameter and the overall purpose. While it lacks explicit exclusionary guidance or error-handling details, it is sufficiently complete for a create tool with three parameters, especially with the generous parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It defines each parameter: name (display name), detail (description), and actions (list of action objects). Most importantly, it elaborates on the complex actions parameter with a detailed JSON example and a list of action types, adding significant meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new flow with a sequence of actions' – a specific verb and resource. It clearly distinguishes from sibling tools like update_flow, delete_flow, and list_flows by focusing on the creation aspect, and it also contrasts with other create_* tools by naming the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a new flow needs to be created. It does not explicitly exclude alternatives or mention update_flow for modifications, but the context is unambiguous due to the name and description. The absence of explicit guidance about when not to use is a minor gap, but the clarity is sufficient.
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?
With no annotations, the description carries the full burden. It clearly implies a read-only list operation and discloses pagination support via page_size and page_token, but does not explain behavior such as result ordering, rate limits, or what happens if no routes exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence. The Args section is a clear, structured list that avoids unnecessary prose, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two optional parameters and an output schema, the description covers the essential purpose and parameter semantics. It lacks explicit statements about pagination behavior (e.g., how to retrieve all pages) and does not discuss when to use get_route instead, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and defaults (0% description coverage). The description compensates by explaining each parameter: 'Number of results per page (default 10)' and 'Pagination cursor from a previous response', adding substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all routing rules in your VoIPbin account' with a clear verb and resource. It also adds context about what routes are, distinguishing it from sibling tools like get_route which targets a single route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose explicit but provides no guidance on when to use it versus alternative tools such as get_route or list_flows. Usage context is implied from the listing verb, but no exclusions or alternatives are mentioned.
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?
No annotations are provided, so the description must carry the behavioral transparency burden. It discloses that engine_key is a sensitive credential that will be sent to the API and may appear in the response, which is valuable context. However, it doesn't mention other behaviors like network calls, rate limits, or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured Args list with one sentence per parameter. It's slightly verbose but every line adds value, and the format aids scannability. It earns a 4, not a 5, because it could be trimmed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no annotations, and an output schema present, the description covers all parameters with meaningful context and doesn't need to explain return values. It's complete enough for an agent to use the tool effectively, though it omits any post-creation behavior or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully by explaining every one of the 9 parameters with examples (e.g., engine_model options, TTS providers) and defaults (stt_language). This adds substantial meaning beyond the bare parameter names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Create a new AI voice agent' – a specific verb and resource that clearly distinguishes this from sibling tools like create_call or create_contact. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description clearly indicates the tool's purpose (creating an AI agent), it does not explicitly explain when to use this versus alternatives. No exclusions or prerequisites are mentioned; usage context is only implicit via the name and sibling list.
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?
With no annotations, the description carries the full burden. It explicitly lists the return fields (status, source, destination, direction, recording IDs, timestamps, current action), giving the agent insight into what to expect. It does not mention error behavior or permissions, but for a read-like 'get' tool, this is sufficient and adds value beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose, and includes an Args section for the parameter. Every sentence earns its place without redundant text. It is well-structured and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter) and the presence of an output schema, the description is adequate. It states the purpose, lists return fields (even though output schema could handle that), and explains the parameter. It does not over-explain, and it covers the essential aspects for a 'get' operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only call_id with no description, so the schema coverage is 0%. The description compensates by explaining 'call_id: The UUID of the call to retrieve,' adding semantic detail that the schema alone does not provide. This goes beyond simply restating the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get detailed information about a specific call.' This distinguishes it from list_calls (which lists calls) and other retrieval tools like get_conversation or get_flow by focusing on a single call and its specific attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a specific call but does not explicitly state when to use this tool over alternatives. No exclusions or alternatives are mentioned. The context is clear enough, but it lacks direct guidance like 'use this instead of list_calls when you need call details.'
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?
No annotations are provided, so the description carries the full burden. It explicitly states that the tool returns account details including name, billing info, and webhook configuration, giving clear behavioral expectations. The 'Get' verb implies a safe read operation, and the description adds context about the return content beyond what a bare name would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The first sentence states the core purpose, and the second adds useful detail about return fields. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless getter, the description adequately covers the main purpose and return content. Output schema exists, so detailed return structure is not required. It lacks explicit mention of error conditions or authentication, but these are reasonable gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. As per rubric, 0 params yields a baseline of 4; the description need not explain any parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get your VoIPbin customer account information', which clearly states the verb (get) and resource (customer account). It also enumerates specific returned fields (name, billing info, webhook configuration), making the tool's purpose unambiguous and distinguishing it from sibling tools like get_billing or get_number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when customer account details are needed, but it does not provide explicit when-to-use/when-not-to-use guidance or mention alternatives. Given the sibling get_billing, there is no differentiation, so an agent might lack clarity on when to choose this over related 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?
No annotations are provided, so the description carries the burden. It correctly implies a read-only operation and documents pagination semantics (page_token as a cursor from a previous response), but it doesn't disclose rate limits, auth requirements, or ordering/filtering 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a two-sentence introduction and a brief Args list. No sentences are wasted; every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple paginated list operation, and the description covers its core purpose, entity definition, and parameter semantics. An output schema exists, so the lack of return-value explanation is acceptable; it's fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's Args section is essential. It explains page_size as the number of results and page_token as a pagination cursor, adding meaning beyond the schema's type and default fields. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all agents in your VoIPbin account' with a specific verb and resource, and clarifies agents as users handling interactions. This distinguishes it from sibling list tools like list_contacts or list_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what agents are but gives no explicit guidance on when to use this tool versus alternatives such as get_agent for a single agent. Usage is implied by the name and primary statement, but lacks clear exclusions or named 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?
No annotations are provided, so the description carries the full burden. It clearly states the tool lists flows, which implies a read-only operation, and explains what flows are. However, it does not disclose any additional behavioral traits such as pagination semantics (how to detect the last page), ordering, or whether any filters or side effects exist. The description adds domain context but not beyond what is obvious from the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the primary purpose, adds a brief explanatory sentence about flows, and ends with parameter documentation. There is no redundant content; every section serves a clear purpose and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and an output schema, the description is complete. It names the resource, explains the params, and does not need to describe return values because the output schema covers them. No critical information appears to be missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explicitly defining both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response'. This adds meaningful semantics beyond the literal schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence, 'List all flows in your VoIPbin account', clearly states the action (list), the resource (flows), and the scope (VoIPbin account). This distinguishes it from sibling tools like get_flow (retrieve a single flow) or create_flow/update_flow/delete_flow (mutations), and from list_activeflows which likely lists only active flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to list all flows in the account. However, it does not explicitly mention when to use this tool over alternatives (e.g., get_flow for a specific flow, or list_activeflows for active flows), nor does it provide any exclusions or prerequisites. This is adequate but lacks proactive 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?
With no annotations, the description bears the full burden of behavioral disclosure. It adds useful pagination context (page_size default 10, page_token as a cursor), but does not explicitly state that the operation is read-only or mention any permissions, rate limits, or side effects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose stated first, a brief explanatory sentence for context, and a clean Args section. Every sentence contributes value without redundancy or unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a simple list operation with an output schema, the description fully covers the core functionality, pagination parameters, and background on what a queue is. There is no critical missing information for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions, but the description compensates fully via an Args section. It explains page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response,' providing complete semantic meaning for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all call queues in your VoIPbin account,' specifying the exact resource and scope. It also explains what queues are, distinguishing this from sibling tools like get_queue by emphasizing 'all call queues.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives like get_queue. It lacks exclusionary or comparative statements to help an agent choose between similar list_* tools.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'send' without mentioning potential side effects, costs, irreversibility, or any prerequisites. This is a significant gap for a tool that performs a real-world side effect like sending a text message.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose followed by a clear args list. Every sentence adds value, and it includes a helpful format example without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and all three parameters clearly, which is sufficient for a simple messaging tool. An output schema exists, so return value details are not needed. The description is complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only names and types, but the description adds critical meaning by specifying E.164 format for both numbers and clarifying that source_number is 'Your VoIPbin phone number' and destination_number is the recipient. It also gives a concrete example, fully compensating for zero schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Send an SMS message,' which is a specific verb and resource. It clearly distinguishes itself from sibling send_email by explicitly stating SMS, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that this tool sends SMS messages, which is enough to understand when to use it. It does not explicitly mention alternatives or exclusions, but the SMS focus implicitly differentiates it from send_email and other communication 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?
No annotations are provided, so the description carries the full burden. It explains the parameters and defaults (e.g., service_level, end_handle) but does not disclose side effects, permissions, or return behavior. For a create operation, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a single opening sentence followed by a clean Args list. Each parameter gets one brief line, with no redundant explanations or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, some with implicit enums) and the presence of an output schema, the description covers the essential inputs. It might benefit from noting any prerequisites (e.g., existing flows for actions), but it is complete enough for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter with examples or value sets (e.g., campaign_type: 'call', 'sms', 'email'; end_handle: 'stop', 'loop', 'next'). This adds critical meaning beyond the schema's bare property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create a new outbound campaign,' which uses a specific verb ('create') and resource ('campaign'). This clearly distinguishes it from sibling tools like update_campaign, delete_campaign, and list_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for creating campaigns and provides parameter details. While it doesn't explicitly state when not to use it or name alternatives, the context of a create operation is clear, and no exclusions are needed.
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?
No annotations are provided, so the description carries the burden. It discloses pagination behavior (page_token as cursor, default page_size) and clarifies the resource scope. It does not explicitly state read-only behavior, but 'list' implies it. The description adds value beyond the schema by explaining what active flows are.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It front-loads the purpose, provides a clear definition, and lists arguments succinctly. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the key contextual aspects: what is listed, what constitutes an active flow, and pagination parameters. It lacks explicit usage guidance vs alternatives, but overall the context is sufficient 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response.' This adds clear meaning beyond the raw schema type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all currently running active flows.' It uses a specific verb (list) and resource (active flows), and further clarifies that active flows are flow instances executing on calls, distinguishing it from flow definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by defining active flows as 'currently executing on calls,' but it does not explicitly mention alternatives or exclusions. Siblings like list_flows and get_activeflow exist, but no direct comparison or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the result is paginated and lists specific fields returned (status, source/destination numbers, direction, timestamps). However, it does not mention authentication requirements, rate limits, or ordering semantics, which are relevant for a list operation. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences for purpose and return fields, followed by an Args list. It front-loads the primary purpose and keeps every sentence informative. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects for a simple paginated list tool: what it lists, the return fields, and the parameters. Since an output schema exists, the return format is documented elsewhere. The only minor gap is the absence of any mention of authentication or the relationship to other call-related tools, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its parameters, but the description provides clear, concise explanations in the Args section. It explains that page_size sets the number of results per page with a default of 10, and page_token acts as a pagination cursor from a previous response. This adds meaningful semantic context beyond the schema's bare type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all calls in your VoIPbin account.' This uses a specific verb ('List') and resource ('calls'), and the distinction from siblings like get_call, create_call, and hangup_call is clear. The clarification that it returns a paginated list further refines the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (to list all calls), but it does not explicitly mention when not to use it or suggest alternatives like get_call for a single call. There is no exclusionary guidance, so it earns a 4 rather than a 5.
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?
No annotations are present, so the description carries the full burden. It discloses pagination behavior via the args but does not explicitly state read-only nature, error handling, ordering, or other edge-case behaviors. The conceptual grouping note adds useful context but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary action, and includes only essential information: a clear purpose statement, a brief conceptual note, and parameter explanations. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (simple paginated list with two parameters) and the existence of an output schema, the description adequately covers purpose and parameters without needing to explain return values. It is sufficient 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explains both page_size and page_token with meaningful descriptions ('Number of results per page' and 'Pagination cursor from a previous response'), fully compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all conversations in your VoIPbin account' using a specific verb and resource, and further clarifies what conversations group. This clearly differentiates it from sibling tools like list_calls and list_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to list conversations) but does not explicitly compare it to alternatives like get_conversation or mention exclusions. It is straightforward and unambiguous, but lacks explicit alternative 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?
With no annotations provided, the description carries the behavioral burden. It discloses a key behavioral trait: 'All fields are required (full replacement)', indicating that existing values are overwritten. This is significant context beyond what is obvious from 'update', though it does not cover other aspects like auth or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose in the first sentence and parameter details listed in a clean format. There is no extraneous information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential details for a full-replacement update, including the mandatory fields and the meaning of each. The output schema exists, so return values need not be described, but it lacks contextual details such as the structure of 'action objects' or how to obtain the flow_id, leaving it slightly short of complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It does so by providing a brief but clear meaning for each parameter: flow_id, name, detail, and actions. Each parameter's purpose is explicitly stated, adding value beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing flow' with a specific verb and resource. It distinguishes from sibling tools like create_flow, delete_flow, and get_flow by specifying the update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when needing to modify an existing flow, with 'Update an existing flow' providing clear context. However, it does not explicitly mention alternatives or when-not-to-use, so it falls 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.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/voipbin/mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server