Neuratel MCP Server

Official

by Neuratel-AI

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Tools are organized by resource (calls, campaigns, agents, numbers, DNC, knowledge bases, webhooks, conversations, analytics) with clear role separation. Minor overlap exists between analytics tools (get_usage, get_chat_analytics, get_combined_analytics) and between call history tools (get_active_calls, list_calls, get_call), but descriptions provide sufficient differentiation.
Naming Consistency5/5
Nearly all tools follow a consistent verb_noun pattern (create_agent, list_agents, update_agent, start_campaign, pause_campaign, dnc_add_entry). The few exceptions like add_knowledge_from_text and get_agent_required_variables are still descriptive and follow a noun+preposition style that doesn't create confusion.
Tool Count2/5
46 tools is a very large surface for a single server. Even for a broad voice AI platform, the count exceeds the practical threshold for agent tool selection and suggests opportunities to consolidate related operations (e.g., separate DNC tools, separate conversation tools, multiple analytics tools).
Completeness3/5
The server covers core voice/call, agent lifecycle, campaign management, DNC compliance, and conversation messaging well. However, there are missing lifecycle endpoints: campaigns cannot be updated or deleted (only paused/stopped), knowledge bases cannot be deleted or detached individually, and webhooks lack update/delete operations. These gaps create dead ends for management workflows.
Average 4.4/5 across 46 of 46 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- 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.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosure. It explicitly states the primary behavior (marking all messages as read), but provides no additional context such as idempotency, irreversible effects, or what happens to the conversation state. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is appropriately concise. Every word contributes to the meaning, and there is no redundant or missing structural information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no annotations, the description is minimally adequate—it states the core action. However, it lacks any usage context, return behavior, or edge-case information, so it is not fully complete for an agent to understand its full effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain the conversation_id parameter. Although the parameter's purpose is inferable from the tool name, the description adds no semantic value beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Mark all messages in a conversation as read.' It uses a specific verb ('mark') and resource ('conversation'), which distinguishes it from sibling tools like get_conversation or send_conversation_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context in which this should be used, leaving the agent to infer based on the 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?
With no annotations, the description carries the full burden. It usefully discloses that the copy is independent and duplicates all configuration. However, it omits details about permissions, side effects, error handling, or what happens if the optional new_name is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise main statement followed by a bulleted list of use cases. All sentences add value, though the list could be trimmed without losing core meaning. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description is sufficient to understand the core operation: what is duplicated and that the copy is independent. It omits parameter semantics and error conditions, but those are less critical given the tool's simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions the new_name parameter. It only implicitly references agent_id as the source agent. The optional naming behavior is entirely undocumented, leaving a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create an exact copy of an agent with all its configuration.' This clearly distinguishes the tool from siblings like create_agent, update_agent, and delete_agent by emphasizing duplication and independence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear 'Great for' list with concrete scenarios (A/B testing, language variants, branching, staging/dependencies). It lacks explicit when-not-to-use or alternatives, but the use cases give sufficient context for when this tool 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?
No annotations exist, so the description carries the burden of behavioral disclosure. It reveals return fields (state and progress) and states a monitoring use case. However, the phrase 'List all' conflicts with the existence of a limit parameter with default 20, which is never mentioned. This omission leaves pagination and default behavior ambiguous, a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short paragraphs, front-loaded with purpose, then return details, then use cases. Every sentence earns its place without fluff or repetition. It is easy to scan and clearly organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional param, output schema present), and the description covers return values and use cases. However, the 'all' vs limit mismatch is not resolved, and the output schema's actual fields are not described (though the presence of an output schema lowers that burden). Overall, it is mostly complete but leaves a critical behavioral ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, limit, is completely undocumented in the description. Schema description coverage is 0%, so the description must compensate, but it does not. An AI agent is left to guess whether limit controls page size, max results, or something else. This is a major gap for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'List all outbound campaigns with current status and progress.' It clearly distinguishes this tool from sibling get_campaign (which retrieves a single campaign) and lifecycle tools (start/pause/stop) by focusing on listing and monitoring. Enumerating campaign states (draft, running, paused, completed, stopped) adds precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this to find campaign IDs for start/pause/stop operations, or to monitor overall campaign health at a glance.' This tells the agent when to use this tool and implies when not to (e.g., for a single campaign's details, use get_campaign). It also names the related lifecycle operations, giving clear 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?
There are no annotations, so the description carries the burden of behavioral disclosure. It reveals that the tool interleaves messages and voice sessions chronologically, which is a key behavior. However, it does not disclose details like whether the timeline is ascending/descending, how pagination works, or what the response structure looks like. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded: the first sentence states the core action, and the second adds context on when to use it. Every sentence earns its place, though it could be slightly more structured (e.g., explicit parameter notes) without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (4 params, output schema exists), so the description doesn't need to explain return values. It covers the primary use case and differentiates from siblings. The lack of pagination details is a minor gap but not critical given the schema provides types and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not add any parameter-specific semantics beyond the schema itself. The parameters (limit, since, before, conversation_id) are self-explanatory from their names and types, so the baseline of 3 is appropriate given the schema is decent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('unified timeline of messages + voice sessions for a conversation'), making the tool's function immediately clear. It also distinguishes itself from likely sibling tools like list_conversation_messages by emphasizing the interleaved chronological merging of both message types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when this tool is useful ('when a contact has both chat exchanges and call attempts on the same thread'), providing clear context. It does not explicitly name alternative tools or say when not to use it, but the usage context is specific enough to guide an 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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It describes what the tool returns and the channel scope, but does not mention side effects, authentication, rate limits, or read-only assurances. The 'Get' verb implies a safe read, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and contains only essential information. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description lists the key KPIs, which is useful. However, with 5 undocumented parameters and no annotations, the overall context is incomplete. The description gives basic usage but lacks deeper parameter guidance and edge-case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all 5 parameters. The description adds some context ('SMS + WhatsApp' hints at valid channel values, 'requested window' relates to start/end dates) but does not explain the interval parameter, agent_id, or how parameters interact. With no schema descriptions, the description insufficiently compensates for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves chat-channel KPIs (SMS + WhatsApp) and enumerates specific metrics (inbound/outbound counts, latency, agent utilisation, outcomes). This is a specific verb+resource and distinguishes it from the sibling tool get_combined_analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names an alternative tool: 'For combined voice + chat KPIs use get_combined_analytics instead.' This provides clear when-to-use/when-not-to-use guidance and differentiates the tool from a closely related sibling.
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 behavioral disclosure. It adds useful behavior: conversations group messages/voice sessions per contact/channel, channel can be omitted, and limit has a default and maximum. However, it does not clarify status lifecycle values, ordering, or explicitly confirm read-only behavior beyond the verb 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line summary, a one-sentence definition of a conversation, and a concise Args list. Every sentence earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return formats. It covers the core listing purpose, channel filtering, and limit behavior. Gaps such as status values and ordering prevent a perfect score, but it is still a solid description for an inbox-style listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description's Args block is essential. It explains 'channel' with enum values and omit behavior, and 'limit' with default and max. The 'status' parameter is only described as 'Conversation lifecycle filter', which is too vague to help the agent choose valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List conversation threads across SMS, WhatsApp, and voice.' It clearly defines what a conversation is and explicitly differentiates from sibling tools like list_calls and list_conversation_messages by emphasizing channel-based grouping and inbox-style review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this for inbox-style review' provides clear usage context, and the channel parameter signals the intended filtering use case. It does not explicitly name alternatives or exclusions, but the description's scope makes it clear when this tool is appropriate.
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 full burden. It discloses the complete return payload and even describes the transcript structure, which is helpful. However, it does not mention edge cases like invalid call_id behavior or authentication requirements, though these are less critical for a read-only retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, a detailed list of returned data, a helpful example of transcript format, and final usage guidance. It is somewhat verbose but every section contributes value; the transcript example in particular justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-ID retrieval tool with an output schema, the description is comprehensive: it covers what to expect, how to use it, and common queries. It does not discuss errors or pagination, but these are not necessary given the tool's simplicity and existing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies call_id identifies the voice session but never explicitly explains the parameter format or how to obtain it. The single required parameter is self-explanatory from its name and context, but the description adds minimal value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full details for a specific voice session including transcript' and lists the full set of returned data (transcript, summary, recording URL, etc.), making it obvious what the tool does. It distinguishes itself from siblings like list_calls by emphasizing the detailed, single-session focus and explicit use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context with 'primary tool for post-call analysis' and explicit example queries like 'What happened on that call?' and 'Show me the transcript.' However, it does not explicitly mention when not to use it or name alternative tools (e.g., list_calls for a list of calls), so it lacks exclusionary 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 provided, the description carries the full burden of behavioral disclosure. It explains that the tool returns a summary per agent and that full configuration requires get_agent, which is useful. However, it does not clarify the behavior of the 'limit' parameter or pagination, and the phrase 'List all' may mislead given a default limit of 20.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the purpose, the second paragraph gives concrete use cases, and the third explains the output and directs to get_agent. Every sentence contributes meaningful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete for a simple list tool, covering purpose, use cases, and relationship to get_agent. The presence of an output schema reduces the need to explain return values, but the description omits any mention of the 'limit' parameter or pagination behavior, which is a notable gap for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'limit' parameter, and the description does not mention or explain this parameter at all. Since the description must compensate when schema coverage is low, this is a significant gap. The parameter name is somewhat self-explanatory, but the description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'List all voice AI agents in your organization.' It explicitly differentiates from sibling tools by noting it returns summaries and directing users to get_agent for full configuration, which distinguishes it from get_agent and other agent-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to find agent IDs for making calls, starting campaigns, or assigning to phone numbers, and to audit agent existence/activity. It also provides an alternative by recommending get_agent for full configuration, giving clear when-to-use and when-not-to-use 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, the description carries the full burden. It discloses the return content (configuration, execution stats, performance data) and notes that it's 'real-time,' which are valuable behavioral traits. However, it does not mention error behavior, permissions, or that it's a read-only operation, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three succinct sentences, with the main purpose in the first line and necessary details following. No redundant words, and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema (one param) and an output schema, so the description only needs to provide high-level behavioral context. It covers the main use cases and return categories, making it reasonably complete. Minor omission is how to obtain campaign_id, but this is a standard and minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain the campaign_id parameter. However, there is only one required parameter with a self-explanatory name, and the tool's purpose implies the identifier's role. This mitigates the gap, but the description adds no direct value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Get full details and real-time progress for a campaign.' It distinguishes from siblings by emphasizing full configuration, execution stats, and real-time progress, which differs from list_campaigns (likely summary) and get_active_calls/get_call (focused on calls).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are provided: 'monitor a running campaign, debug why calls are failing, or review results after completion.' This gives clear context, but no comparison to alternatives or when-not-to-use is mentioned, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It explains key behavior: protection_enabled=false logs but does not enforce DNC checks, and auto_add_inbound_optouts enables inbound STOP detection. It does not mention null-handling or other side effects, but provides valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a concise args list. Every word adds value, with no fluff or repetition. The structure is clear and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers both parameters' functionality and effects. It doesn't explain the null-null case or explicitly mention return/response, but an output schema exists. Minor gaps in usage guidance prevent a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains both parameters: protection_enabled as a master switch with explicit consequences when false, and auto_add_inbound_optouts as a watcher for STOP-style language. This adds rich meaning well beyond the schema's type/default info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Toggles DNC protection and inbound STOP auto-detection,' specifying the verb and resource. It distinguishes itself from sibling tools like dnc_get_settings (read) and dnc_add_entry (add) by focusing on updating settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for changing DNC settings but does not explicitly state when to use this tool versus alternatives like dnc_get_settings for reading or dnc_check for lookups. No alternatives are mentioned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers detailed behavioral context. It explains the return split into system_variables and dynamic_variables, clarifies that system variables are platform-injected and should never be supplied, and notes that sources/categories are included 'where possible.' This goes beyond a simple read-only list and provides valuable insight into the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It begins with a clear summary sentence, uses bullet points to delineate variable categories, and ends with a practical usage tip and rationale. Every sentence provides useful information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is quite complete for a one-parameter tool, covering purpose, return structure, and usage. An output schema exists, so return-value details are covered there. However, it does not mention potential error conditions or explicitly relate to sibling tools like get_system_variables_catalog, which would enhance contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, agent_id, with 0% schema description coverage. The description does not mention or explain this parameter at all. While the parameter name is self-explanatory, the description adds no semantic value to the schema, so it does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List the {{variable}} placeholders an agent needs at call time.' It uses a specific action verb and resource, and distinguishes itself from siblings by detailing the two categories of variables (system and dynamic). This makes the tool's function immediately evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool: 'Use this before placing an outbound call to verify the dynamic_variables payload covers every required name.' It also warns 'never supply' system variables. However, it does not explicitly name alternative tools (e.g., get_system_variables_catalog) or state when not to use it, so it falls slightly short of a perfect score.
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 full burden and does well by disclosing the return envelope fields and the notable exclusion of message history. It stops short of mentioning error conditions or access requirements, but the core behavioral trait (what you do and do not get) is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, and the second adds important return details and a pointer to the sibling tool. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param) and has an output schema, so the description does not need to detail return values. It covers the key differentiators: envelope fields, exclusion of message history, and the correct sibling tool for messages. It could mention relationship to get_conversation_timeline, but this is not essential for a basic getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, conversation_id, and the schema merely says it is a string (schema description coverage is 0%). The description does not add any detail about the required format, where to find the ID, or its exact role beyond the name. With zero coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('single conversation thread'), states it returns the 'conversation envelope' with key fields, and explicitly distinguishes itself from list_conversation_messages by noting it does NOT return message history. This clearly separates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to 'Use list_conversation_messages for the messages,' giving concrete guidance on when not to use this tool and which alternative to choose. This makes the usage context unambiguous.
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 transparency burden. It discloses ordering (newest first), default limit, and timestamp filters. However, it does not mention pagination, whether the operation is read-only, or any error/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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence purpose followed by a short labeled Args block. Every line adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are documented with behavioral context, and the output schema covers the response format. Minor gaps exist around pagination/limits, but the description is sufficiently complete for an agent to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and defaults; the description adds crucial meaning: source of conversation_id, meaning of limit, and ISO 8601 format for since/before. This fully compensates 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('List messages exchanged in a conversation') and adds ordering ('newest first'). This clearly distinguishes it from sibling tools like get_conversation or send_conversation_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite: conversation_id comes from list_conversations. However, there is no explicit mention of when not to use it or alternatives. The usage context is well implied and the prerequisite is useful.
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?
Since there are no annotations, the description carries the burden of disclosure. It transparently states that calls will not be answered, the number still exists, and it can be reassigned later. It could go further by mentioning permissions or effects on active calls, but the key side effects are clearly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose, then provide a clear use-case list. Every sentence adds meaningful information with no filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter operation, an output schema is present, and the description explains the outcome, persistence, and reassignment. Minor gaps remain around parameter acquisition and active-call behavior, but for this tool's complexity the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate, but it never explicitly explains phone_number_id. The agent can infer that the parameter identifies the phone number from the tool name and context, yet no guidance is given on how to obtain the ID or validate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Remove the agent from a phone number' and clearly states the consequence ('inbound calls stop being answered'). This distinguishes the tool from the sibling assign_number by describing the removal and the fact that the number remains reassignable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: retiring a number, switching agents (with the concrete instruction to unassign then call assign_number), or taking a number offline for maintenance. This is exactly the kind of when-to-use guidance that helps an agent choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the response's broad coverage (brain, voice, transcriber, etc.) and adds a valuable behavioral fact: the response structure matches update_agent's config parameter, enabling a read-modify-write cycle. It stops short of explicitly stating 'read-only, no side effects,' but the verb and context strongly imply it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short paragraphs, each with a distinct purpose: purpose, field coverage, usage guidance, and schema compatibility. The field list is slightly verbose but informative. Overall it is front-loaded with the primary action and avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool returns, when to use it, and how its output integrates with update_agent. An output schema exists, so return format details are handled elsewhere. For a single-parameter read tool, this description is comprehensive and leaves little to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (agent_id) exists, and the description implies its meaning by saying 'a specific agent,' but does not explain what the ID is or how to obtain it. Since the schema provides no description either, the description offers minimal compensation. The parameter is simple enough that meaning is inferable, but not fully explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get the complete configuration of a specific agent,' which is a specific verb+resource+scope statement. It clearly differentiates from sibling tools like list_agents (which lists) and update_agent (which modifies) by emphasizing the complete configuration and full behavioral picture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this before calling update_agent to understand current state, or to inspect how an agent is configured for debugging call quality issues.' This names concrete scenarios and creates a workflow with update_agent, making the when-to-use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by explaining the exact behavior: no new calls are placed, active calls finish naturally, and the campaign retains its progress. This goes beyond a simple 'pause' and discloses key side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the main action, then detailing behavioral effects, resumability, and use cases. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is largely complete: it explains what the tool does, the behavioral effects, and when to use it. It doesn't address error cases (e.g., pausing an already-paused campaign), but this is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines campaign_id as a required string with no description, and the description does not explicitly discuss the parameter. However, the tool name and description make it clear that campaign_id identifies the campaign to pause, and the phrase 'running campaign' implies a constraint on the parameter value. This provides minimal added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Pause a running campaign') and differentiates from sibling tools by explaining that active calls finish and the campaign can be resumed, unlike stop_campaign. The verb 'pause' and the resource 'running campaign' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: throttle costs, investigate quality issues, or pause during off-hours. It also mentions resumption via start_campaign, giving clear guidance on when to use this tool. However, it does not explicitly contrast with stop_campaign for termination, so a slight gap remains.
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 transparency burden. It thoroughly discloses replacement behavior ('assignment is replaced'), immediate routing, and that the agent uses its configured settings. It does not mention permissions or errors, but covers the core behavioral effects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement, behavioral details, and an Args list. It is slightly verbose but each sentence adds meaningful detail, earning a high score without being maximally terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers purpose, side effects, and parameter sourcing. Since an output schema is indicated, return values need not be described. Minor aspects like ID validation or failure behavior are absent, but overall it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description compensates by explaining that phone_number_id is 'the number to configure (from list_numbers)' and agent_id is 'the agent that will answer calls (from list_agents)'. This adds meaning and source references, though without extensive format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: routing a phone number's inbound calls to an AI agent. It distinguishes itself from the sibling tool unassign_number (opposite action) and explicitly contrasts with make_call for outbound calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context and clearly states 'This only affects inbound calls. For outbound calls, you specify the agent and number separately in make_call.' This names an alternative tool and gives a clear exclusion, meeting the highest bar.
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 full burden. It discloses important behaviors: server-side defaults, turn_detection mode, recording retention, post-call analysis, and BYOK requirements for Soniox. It could also mention side effects like agent uniqueness, but the coverage is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but highly structured with headers, bullet lists, and a code example. It is front-loaded with the core requirement and every section adds necessary detail for a 20-parameter tool. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 params, multiple providers, advanced config), the description is remarkably comprehensive. It covers required fields, defaults, provider options, configuration examples, and return values. It fully compensates for the bare schema and lacks only minor exclusions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. It details valid providers and models for brain, voice, and transcriber, explains the config dict, and clarifies important defaults. However, a few parameters like tags, max_tokens, temperature, and first_message_delay_ms are not explained individually, though they are standard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new voice AI agent,' using a specific verb and resource. It clearly distinguishes from siblings like update_agent, delete_agent, and get_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is for creating a new agent, with only name and instructions required. However, it does not explicitly mention when to use update_agent for modifications or list alternative tools, though the create context is obvious.
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 and discloses the key side effect: 'all subsequent outbound calls (manual or campaign) to this number from your org will be blocked at dial time.' It also mentions the optional reason. However, it doesn't address idempotency or reversibility (via dnc_delete_entry).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and front-loaded, with only 3 sentences and a clear Args block. Every sentence adds value, and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and side effect, and output schema likely exists on the tool, so return values don't need explanation. It misses minor edge cases like duplicate additions or how to remove the entry, but overall it's sufficient for a simple add tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by documenting both parameters: phone as 'E.164 formatted number' and reason as 'Optional human-readable reason' with examples. This adds format, optionality, and examples beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a number to your organization's DNC list' with a specific verb and resource. It also explains the consequence (blocking outbound calls), which distinguishes it from siblings like dnc_check or dnc_delete_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to prevent outbound calls to a number, but it doesn't explicitly name alternatives or when-not-to-use. It gives clear context about the effect, which is enough for most agents to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the key behavioral nuance: the entry is 'soft-expired (audit-preserved), not hard-deleted.' It also notes that platform-managed entries are immutable, which sets expectations about authorization. It does not describe error cases or return value, but the output schema likely covers the latter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear opening statement followed by constraints and an Args block. Every sentence adds information without redundancy, and key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description covers the essential context: action, eligibility, behavior, and parameter provenance. It fully equips an agent to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, but the description compensates by explaining that entry_id is 'ID returned by dnc_list_entries or dnc_add_entry,' adding source context beyond the bare schema. This is sufficient for a single simple string parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Soft-expire' with a clear object 'org_upload DNC entry,' immediately conveying the tool's action and scope. It also distinguishes this from siblings by noting it only applies to org_upload entries, not platform-managed ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool applies ('Only org_upload entries can be removed') and when it does not ('Platform-managed entries are immutable to org admins'), providing clear exclusions. However, it does not mention an alternative tool for platform-managed entries, but that is acceptable since none appears available.
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?
Given no annotations, the description discloses the exact settings returned and their meanings (protection_enabled and auto_add_inbound_optouts), adding behavioral context beyond a simple getter. It doesn't mention error cases or permissions but that's acceptable for a simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences serve distinct purposes: one states the operation, one explains return values. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and a simple return structure; the description covers the purpose and the meaning of the return fields adequately. Sibling tools exist but the description is sufficient for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline for parameter semantics is 4. The description correctly avoids inventing parameter explanations where none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'organisation's DNC protection settings', clearly distinguishing it from DNC mutation tools like dnc_update_settings and dnc_check which operate on individual entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies retrieval of settings but doesn't explicitly contrast with sibling tools like dnc_check for individual lookups or dnc_update_settings for modifications. The context is clear, but no when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses that this is a read-only catalog, implying no side effects. It also describes the output components (name, description, full agent config block), offering solid transparency for a simple 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each providing value: what it is, why it's useful, and what templates include. It is front-loaded with the purpose and contains no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool with an output schema, the description covers the purpose, use case, and output content sufficiently. It need not explain return values in detail since the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is no parameter information to add. The description does mention deep-merging overrides, which adds context about the output but not parameters. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists pre-built agent templates, using the specific verb 'List' and resource. It distinguishes from sibling tools by framing these as starting points for customization via create_agent, which avoids confusion with 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says these templates are useful as starting points before customising via create_agent, providing a clear usage context. However, it does not explicitly mention alternatives or when-not-to-use, so it falls short of a full 5.
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 full burden, and it clearly communicates a read-only behavior via the verb 'List' and the phrase 'before creating duplicates,' implying no side effects. It adds valuable domain context about RAG, which helps the agent understand the tool's role. It does not mention permissions or pagination, but this is a simple list operation and the output schema covers return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear opening sentence stating the purpose, followed by a brief explanation of knowledge bases, and then a direct usage note. Every sentence adds value, and the overall length is appropriate for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list operation with an output schema, the description is complete. It explains what is being listed, why knowledge bases matter in the RAG context, and when to use the tool (e.g., before creating duplicates, to find IDs). No additional information is needed 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so parameter semantics are minimal. The description's phrase 'all knowledge bases in your organization' confirms the scope, and there are no parameter details to document. The baseline score for zero-parameter tools is 4, and the description meets that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all knowledge bases in your organization,' which is a specific verb+resource that clearly states what the tool does. It also adds context by explaining what knowledge bases are (documents, FAQs, web content used in RAG), which differentiates it from sibling tools like add_knowledge_from_text or attach_knowledge_to_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this to see what knowledge exists before creating duplicates, or to find knowledge_base_ids for attach_knowledge_to_agent.' It names a sibling tool for a follow-up action, providing clear usage context. However, it does not explicitly mention when not to use it or list alternative tools for similar purposes.
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 transparency burden. It discloses output fields and offers interpretive guidance for failure_count, which adds value beyond a simple list operation. It doesn't mention rate limits or auth, but the tool is a simple read-only list with no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding value: what it does, what fields it shows, when to use it, and how to interpret a key field. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description covers purpose, usage, and interpretation. It complements the sibling create_webhook tool and nothing essential is missing 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters, so the baseline for this dimension is 4. The description appropriately does not invent parameter details and effectively covers the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('configured webhook subscriptions'), and distinguishes itself from siblings like create_webhook by clearly stating it shows webhook details. It enumerates the fields returned, leaving no ambiguity about its 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides use cases ('audit integrations', 'check for delivery failures', 'verify that the right events are being captured'). It does not explicitly mention when not to use it or alternatives, but the context is clear and actionable.
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 and does well: it explains the call is handled autonomously, agent_override is a non-persistent deep-merge, and a balance prerequisite is mentioned implying cost. It could add explicit warnings about charges or call duration limits, but overall discloses key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-structured with headers, bullet lists, and an example override JSON. The core action and prerequisites are front-loaded, and the length is justified by the tool's complexity. Some trimming of the customization section could improve conciseness, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, 7 parameters, and existing output schema, the description covers prerequisites, required vs optional fields, per-call customization, and return values (call_id, success status, numbers). It references sibling tools for tracking and setup, making the description self-sufficient for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's Args section compensates richly: E.164 format, max 50 chars for caller_id_name, default behavior for caller_id_number, and detailed examples for dynamic_variables and agent_override with deep-merge semantics. Every parameter is given meaningful context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Place an outbound phone call using a voice AI agent,' which is a specific verb+resource statement that clearly distinguishes this from siblings like hangup_call, list_calls, and get_call. It unambiguously identifies the action and the object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Prerequisites explicitly point to sibling tools (create_agent, list_agents, list_numbers, get_balance) and the 'Minimum required' section clarifies the essential fields. It stops short of explicitly saying 'when not to use' but provides clear context and alternatives via the prerequisite 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?
With no annotations, the description carries the transparency burden. It discloses useful traits like freeform vs. templated sending and the client_temp_id dedup key, but it does not mention side effects (e.g., message persistence/delivery), required permissions, or rate limits. It stops short of being fully transparent for a mutating 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a compact Args block. Every sentence contributes meaningful guidance, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is well-covered given its moderate complexity: all parameters are explained, an output schema exists, and usage boundaries are explicit. It lacks minor operational details such as failure modes or auth prerequisites, but these are not critical for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section fully compensates by explaining all four parameters: conversation_id target thread, body message text required, media_urls optional media list, and client_temp_id optional dedup key. This adds meaning far beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Send an outbound message into an existing conversation.' It also distinguishes this tool from templated WhatsApp sends, clarifying its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'For SMS / WhatsApp freeform replies' and direct alternative guidance: 'Templated WhatsApp sends should use the agent's WhatsApp template config instead of this tool.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: dialing begins immediately, calls respect a concurrency limit, calls continue until all contacts are reached or campaign is paused/stopped, and insufficient credits cause mid-campaign failures. This is comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action. Each sentence adds essential information: status prerequisites, behavioral details, and a financial warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, one parameter, and no annotations, the description covers prerequisites, runtime behavior, and a necessary prerequisite check. The presence of an output schema covers return values, so the description is complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter campaign_id is not explicitly described in the schema or description. However, the surrounding context ('The campaign must be in...') implies it identifies the campaign to start. Since schema coverage is 0%, the description partially compensates but could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Start a campaign — begins dialing contacts immediately.' This uses a specific verb and resource, and the mention of dialing distinguishes it from sibling campaign tools like pause_campaign and stop_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: the campaign must be in 'draft' or 'paused' status, and it advises checking get_balance before starting. It does not explicitly name alternative tools for pausing/stopping, but the conditions and prerequisite are clear.
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 discloses key behaviors: permanence, inability to restart, abandonment of uncalled contacts, completion of in-progress calls, and status marking. It lacks details like return formats or error handling, but the essential side effects are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the primary action in the first sentence. Each subsequent sentence adds crucial information (irreversibility, contact handling, in-progress calls, alternative tool) without redundancy. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter mutation with an output schema, the description is complete. It covers all major aspects: what happens to the campaign, remaining contacts, in-progress calls, and the alternative tool. No critical information is missing for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only campaign_id with no description, and the description does not explicitly explain the parameter. However, the parameter is trivially understood from the tool name and context. The description implies the target campaign but does not add meaningful detail beyond the schema, so a mid-range score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Stop a campaign permanently' and specifies the key effect: remaining contacts will not be called. It explicitly differentiates from sibling pause_campaign by noting this action is final, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool instead of alternatives: 'Unlike pause, stopping is final' and 'Use pause_campaign instead if you might want to resume later.' This directly addresses the decision between stop and pause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility for behavior disclosure. It covers deep-merge semantics (only provided fields are changed), the requirement for provider fields with voice/transcriber sections, and the override rule (named params override config sections). It also warns about validation failure due to discriminated unions, which is critical for correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with headers, code examples, and a warning section. Each part contributes meaningful information, and the front-loaded purpose statement ensures quick orientation. It could be trimmed slightly but is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (22 parameters, nested config), the description thoroughly covers merge behavior, provider requirements, and the complete config schema. It does not describe return values, but an output schema exists, so that's not required. It omits error cases or permission notes, but for an update tool with this depth, it is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the config parameter in extensive detail with a full code block listing sections and fields. It also names several common parameters (temperature, voice_speed, voice_id, etc.) and their roles. However, not all 22 parameters are individually discussed, though many are self-explanatory by name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update any part of an agent's configuration,' which clearly states the verb (update) and resource (agent configuration). This distinguishes it from sibling tools like create_agent, delete_agent, and get_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly outlines two usage paths: named parameters for common changes and the config parameter for other sections. It also advises calling get_agent first to see the current structure, providing clear context. However, it doesn't explicitly state when not to use this tool (e.g., for creation), but the sibling list and context make this obvious.
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 of behavioral disclosure. It explains that variables are 'inherited by any subsequent voice/chat turn that renders the agent's prompt template' and details the 'replace' parameter's merge vs. replace behavior. This provides key behavioral transparency, though it could mention additional aspects like error handling or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with the core purpose, then provides a brief usage note, and includes an 'Args' list for parameter details. Every sentence earns its place, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, usage, parameters, and behavioral nuances. Given that an output schema exists, the description need not explain return values. It does not address edge cases like invalid conversation IDs, but the provided context is sufficient for typical usage, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having 0% description coverage, the description's 'Args' section explains each parameter's purpose and behavior: conversation_id is the target thread, dynamic_variables is a dict of name/value pairs, and replace controls merge vs. replace semantics. This goes well beyond the schema types and defaults, adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set or update dynamic_variables on a conversation thread.' It specifies the resource (conversation thread) and the action (set or update), which distinguishes it from sibling tools like send_conversation_message or get_conversation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Useful when context arrives out-of-band (CRM sync, webhook from your system, etc.).' This implies when to use the tool, but it does not explicitly state when not to use it or name alternative tools. Still, the guidance is useful and clear.
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 full burden and it delivers: it discloses immediate chunking/indexing, the 500KB size limit, and expected retrieval behavior. However, it does not mention failure modes, uniqueness constraints, or whether creation is irreversible, which keeps it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (overview, workflow, best-for, tips, args) and all content is useful. It is a bit long, but each sentence earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity and an output schema exists. The description covers the full lifecycle (create, then attach to agent), gives content type guidance, size limits, and parameter details. It is complete for practical use, though it could mention error handling or uniqueness requirements for a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates thoroughly with an Arg section explaining each parameter: name (display name with examples), text (content to index, format), and description (organizational purpose). This adds meaning well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a knowledge base from plain text content', a specific verb+resource that clearly states the tool's function. It distinguishes from the sibling add_knowledge_from_url by emphasizing 'plain text' and explains the purpose via chunking/indexing for RAG retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Best for: FAQs, product specs, policies...' and provides practical tips for content preparation such as using headings and Q&A format. It also tells the user to use attach_knowledge_to_agent afterward, clarifying the workflow and alternative/next steps, making when-to-use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states irreversibility, the impact on assigned phone numbers, that active calls continue, and that new calls become impossible. This is rich behavioral context that goes far beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the core action. Every sentence adds essential information: irreversibility, side effects, and a safer alternative. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and the description covers the critical behavioral aspects, the alternative, and the irreversible nature. An output schema exists, so return-value details are not needed. The description is fully adequate for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (agent_id) with zero description coverage. The tool description does not mention the parameter at all, failing to compensate for the lack of schema documentation. Although the parameter name is self-explanatory, the description should explicitly confirm what agent_id refers to, especially when schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Permanently delete a voice AI agent,' which is a specific verb and resource. It clearly distinguishes the tool from siblings like update_agent, which can disable rather than destroy, and from read-only tools like get_agent 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends an alternative ('consider using update_agent with is_active=False to disable the agent without destroying its configuration') and provides clear context for when permanent deletion is appropriate. This gives the agent actionable guidance on tool selection.
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 discloses the return composition (both org_upload and platform-managed entries), notes that platform-managed entries block dialing org-wide, and explains the source filter. It lacks details like pagination or read-only nature, but covers the essential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the first sentence stating the core purpose. Every sentence provides value: return composition, filter semantics, and parameter details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and an output schema, the description completely covers what the tool does, what it returns, and how to filter. The provided context is sufficient for correct invocation and understanding the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for parameters (0% coverage), but the description fully compensates by explaining source's allowed values and limit's default. It adds meaning beyond the bare schema, even listing the exact enum values that the schema omits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List DNC entries visible to your organization' with a specific verb and resource. It distinguishes from siblings (dnc_check, dnc_delete_entry, dnc_add_entry) by focusing on listing, and further clarifies the scope (org-uploaded vs platform-managed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool returns and how to filter by source, but does not explicitly mention when to avoid using it or name alternative tools. Since this is a distinct list operation, the implied usage is sufficient for a 4.
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 behavioral transparency burden. It discloses important nuances such as 'Billing is per-second, so total_seconds is the granular metric' and explains the days parameter's limits and default. It does not explicitly state read-only behavior or error handling, but those are largely implied by the 'Get' verb and simple summary nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lean and well-organized: a one-line purpose, two sentences explaining the returned metrics and a billing nuance, and a clear Args section. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) and has an output schema, so the description does not need to detail return fields. It covers purpose, use cases, and parameter semantics, making it fully adequate 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a bare integer with a default for 'days', while the description adds full meaning: it is a look-back period, has a maximum (365), and gives practical examples ('Use 1 for today's usage, 7 for the past week'). This completely compensates 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get usage summary for a time period' and explicitly lists what the summary contains ('how many calls were made, total seconds and minutes consumed, and total amount billed'). This clearly identifies the resource and distinguishes it from siblings like get_balance or get_active_calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states concrete use cases ('cost monitoring, capacity planning, and usage reporting'), giving clear guidance on when to use the tool. However, it does not explicitly mention alternative tools or when not to use it, so it stops short of a full 5.
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 full burden of behavioral disclosure. It reveals that results are sorted by most recent first, includes status/duration/outcome but excludes transcript, and explains filter semantics (e.g., NULL for web sessions). This is strong behavioral context, though it does not address pagination, rate limits, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by return details and filtering options. Every sentence adds value, including the explicit note about missing transcripts and the parameter breakdown. It is appropriately sized for the tool's complexity without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with four optional parameters and no annotations, this description is remarkably complete. It covers return contents, ordering, exclusions, and all parameter semantics. Since an output schema exists, the description correctly focuses on behavioral aspects rather than repeating return schemas, making it 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description compensates thoroughly. Each parameter is explained with allowed values, defaults, and special cases ('channel' options, 'direction' NULL for web, 'limit' range 1-100). This goes beyond the schema and gives the agent everything needed to construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'List recent voice sessions with a summary of each.' It clearly distinguishes itself from siblings by explicitly noting that the transcript is NOT included and directing users to get_call for full transcripts, thereby differentiating from get_call and get_active_calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: for retrieving call history summaries and filtering by channel, direction, or agent. It explicitly points to get_call as the alternative for reading full transcripts. However, it does not mention get_active_calls as an alternative for active/live sessions, so it lacks a complete when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses the real-time nature, enumerates the returned fields (agents, call duration, caller numbers, connection status), and importantly notes that an empty list is normal. This goes beyond basic expectations and sets clear behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured, leading with the core purpose, then data fields, usage scenarios, and an edge-case note. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity (no params) and the presence of an output schema, the description is complete. It covers purpose, usage, return content, and an edge case, leaving no significant gaps for the agent to resolve on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The baseline for 0 params is 4, and the description adds no parameter-specific detail because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Get all voice sessions happening right now across your organization.' It clearly distinguishes this from sibling tools like list_calls by emphasizing real-time active sessions and the specific data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit use cases: 'Use this for live monitoring, to find a call_id for hangup_call, or to check system load before starting a campaign.' This provides clear context, though it does not explicitly state when not to use it (e.g., for historical calls).
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?
Without annotations, the description discloses the return currency behavior (billing currency defaulting to USD), the has_credits boolean, and the operational consequence of a zero/negative balance. This adds meaningful behavioral context beyond a simple 'check' statement, though it could explicitly state the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with purpose, and uses a clear bullet list for usage guidance. Every sentence adds value, with no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (no params, output schema present), the description covers purpose, usage, and key behavioral details. It also references relevant sibling operations for context, making it complete for an agent to invoke appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly omits parameter details. The baseline score of 4 applies since no params exist to explain, and the schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check the current account balance and credit status' with a specific verb and resource. It distinguishes itself from sibling tools like get_usage by focusing on balance and credit, not general usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to check this before outbound calls, campaigns, and any cost-incurring operations, and explains the consequence of insufficient balance. This provides clear when-to-use guidance with no ambiguity.
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 burden of behavioral disclosure. It explains meaningful semantics: each number can be assigned to one agent, agent_id=null means not answering inbound calls, and assigning an agent starts routing. It doesn't explicitly state read-only behavior, but the verb 'List' and the absence of side effects make that clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear first sentence, a brief context paragraph, bulleted use cases, and a final behavioral note. Every sentence adds value, and the formatting makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, this description is complete. It explains the domain, common use cases, field semantics, and connects to sibling tools like assign_number. An output schema exists, so return details don't need to be in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds meaningful context about entity attributes like number_id, agent_id, and capabilities (voice, SMS), which informs the agent about the data model even though no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List all phone numbers provisioned in your organization.' It clearly distinguishes this list tool from siblings like list_agents or list_campaigns, and reinforces the purpose by explaining phone numbers are entry points for calls and caller ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this to' bullet list explicitly states when to use the tool: finding number_id for make_call or create_campaign, checking agent routing, viewing capabilities, and finding unassigned numbers. It also provides an alternative action by referencing assign_number for null agent_id cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It excels by explaining that processing is asynchronous, how to check status, the expected status transitions (processing → ready/error), typical duration (<30 seconds), and failure conditions. It also reveals that JavaScript-rendered pages are handled. This is exemplary 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loaded with a clear one-sentence summary, followed by the process, use cases, constraints, status information, and parameter details. Every sentence adds value without redundancy, making it appropriately sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool involves async scraping and indexing, the description is remarkably complete. It covers purpose, workflow, usage scenarios, constraints, status lifecycle, error states, and parameter meanings. An output schema exists, so return values need not be described, but the description still provides sufficient context 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description includes an 'Args' section with meaningful explanations for each parameter: name (with examples), url (with example URL and requirement), and description (what it covers). This fully compensates for the sparse schema and adds practical guidance beyond type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a knowledge base by scraping and indexing a web page.' It specifies the resource (knowledge base), the method (scraping and indexing a URL), and even describes the pipeline (fetch, extract, convert, chunk, index). This distinguishes it from sibling tools like add_knowledge_from_text, which likely handles raw text input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use: 'Best for: product documentation, help center articles, pricing pages, company info, or any publicly accessible web content.' It also states the URL must be publicly accessible. However, it does not explicitly mention when not to use or direct users to an alternative like add_knowledge_from_text, so it falls just short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It prominently warns 'This REPLACES all current attachments' and explains the multi-KB cross-search behavior, going well beyond a simple mutating action by disclosing destructive/replacement semantics and retrieval behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the purpose, then the critical replacement warning, retrieval behavior, and parameter semantics. Every sentence contributes operational value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no annotations, this description fully equips an agent to select and invoke the tool correctly. It covers purpose, usage, parameter semantics, and the key behavioral gotcha (full replacement). The output schema handles return values, so no additional return-format explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though the schema has zero property descriptions, the Args section adds meaningful semantic detail for both parameters. It clarifies that knowledge_base_ids must be the complete list of IDs, not just new additions, which is crucial for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Connect' and identifies the resource ('knowledge bases to an agent') and the purpose ('for RAG-powered conversations'). This clearly distinguishes it from sibling tools like add_knowledge_from_text or list_knowledge_bases, which handle knowledge creation and listing rather than attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides strong usage context: the agent will automatically search attached KBs when callers ask questions. It also includes the critical instruction that the operation REPLACES all current attachments and explains how to add without removing existing ones. However, it does not explicitly name alternatives or state when-not to use the tool, though no direct sibling does exactly this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral transparency burden. It discloses that webhooks send HTTP POST requests, explains that the signing secret is returned only once and must be saved immediately, and specifies HMAC-SHA256 verification. This is far beyond a minimal description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: purpose, use cases, event types, security, and args. It is well-structured with Markdown headers and bullet lists, front-loaded with the core purpose, and contains no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many event types) and the absence of annotations and schema descriptions, the description is remarkably complete. It covers creation semantics, event selection, security requirements, and parameter details. An output schema exists, so return value explanation is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the input schema having zero description coverage, the description compensates with an Args section explaining all three parameters: 'name' as display name, 'url' as HTTPS endpoint, and 'events' with default behavior (empty = all). It also enumerates every valid event type in dotted notation, giving exact expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear and specific statement: 'Create a webhook to receive real-time notifications for call events.' This identifies the verb, resource, and outcome, and it clearly distinguishes the tool from siblings like list_webhooks (listing) and create_campaign (campaign management).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases ('trigger workflows, update CRMs, log call outcomes, or build real-time dashboards') and detailed event type guidance. It does not explicitly state when not to use the tool or name alternatives, but the context is clear enough that an agent can decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It explains the scope of the lookup (global federal/state lists, platform-curated entries, per-org entries) and the return values (blocked status, source list, timestamps), which goes well beyond a minimal description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear lead sentence, followed by behavioral details, a usage warning, and a parameter section. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter, the description is complete: it explains the purpose, directory scope, return values, and when to use it. An output schema exists to handle the return shape, so no further detail is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'phone' as a required string with no description schema coverage. The description compensates by specifying the E.164 format and providing a concrete example (+12125551234), giving the agent essential parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Check a phone number against the platform DNC directory.' It also distinguishes itself from sibling DNC management tools by focusing on single-number lookup and explicitly listing the returned information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use: 'Always check before placing an outbound call to a new contact' and explains the regulatory consequence. It does not name alternatives, but the intended usage context is unambiguous.
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 full burden of explaining behavior. It does this well by describing the output shape (total volume, success rate, success score, cost, time series), the default behavior of end_date ('defaults to now'), and the possible values for channel and interval. It does not explicitly state 'read-only' or address auth/rate limits, but the 'Get'/'Returns' wording and focus on analytics make the read-only nature clear. A 4 reflects strong coverage without being exhaustive about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and output, then gives a clear pointer to alternatives, and concludes with a compact parameter list. Each sentence serves a purpose; the Args section is structured and avoids redundancy. It is detailed yet easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 6-parameter tool with no annotations and no schema descriptions, the description is fully complete: it explains what the tool returns, what each parameter does, and when to use sibling tools. The presence of an output schema reduces the need to document return structure, but the description still covers the key metrics and time-series behavior, making context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no property descriptions (0% coverage), so the description must compensate fully. It does: every parameter (start_date, end_date, agent_id, channel, direction, interval) is explained with format hints, defaults, and enumerated values. This makes the tool safely invokable without needing external documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get combined voice + chat KPI dashboard,' and lists concrete metrics returned (volume, success rate, sentiment, cost, per-bucket time series). It also distinguishes itself from sibling tools by explicitly stating that per-channel breakdowns should use get_chat_analytics or list_calls instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool's purpose (combined voice + chat analytics) and explicitly names the alternative tools for when a different granularity is needed: 'For per-channel breakdowns use get_chat_analytics or list_calls instead.' This is direct when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden and excels: it discloses that variables are auto-injected at call time, explains the channel fallback behavior, and outlines the entry structure. This goes beyond a simple 'list' and provides valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, bullet points for use cases, and a concise final sentence about return fields. Every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema present), the description is complete. It covers purpose, usage, and return format, and it handles lack of annotations by providing thorough context, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds relevant context by clarifying that system variables are not passed in dynamic_variables, which indirectly reinforces the no-parameter expectation for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly defines the resource ('platform's built-in system__* template variables'). It distinguishes itself from sibling tools by focusing on the system variable catalog, a unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the catalog (to validate placeholders, distinguish variable types) and provides a concrete 'when not' by noting these variables should never be passed in dynamic_variables. This is clear usage guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it excels. It discloses that this only defines campaign parameters and does not start dialing unless scheduled_start is set, explains concurrency behavior and cost implications, and notes that agent handles calls autonomously. This is rich behavioral context beyond what any annotation could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headers, a sequential workflow, prerequisites, and an args list. While lengthy, every sentence earns its place by adding actionable information—no fluff. The front-loaded summary ensures quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the lack of annotations, and the 0% schema coverage, this description is exceptionally complete. It covers the full workflow, prerequisites, concurrency guidance, and parameter details. Since an output schema exists, the description appropriately avoids explaining return values, focusing on the behavioral and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the 'Args' section explains every parameter in plain language, including the ISO 8601 format for scheduled_start, the default for max_concurrent_calls, and the meaning of call_list_id. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Create an outbound calling campaign to dial a list of contacts.' It clearly distinguishes this from sibling tools like start_campaign, pause_campaign, and get_campaign by explicitly outlining the campaign lifecycle where this tool only creates and configures the campaign, not starts or monitors it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance through a numbered workflow that places this tool as step 1, followed by start_campaign. It also lists prerequisites (create_agent, list_numbers, call_list_id) and references sibling tools for each subsequent action, giving clear context on how this tool fits into the broader process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It clearly conveys the abrupt, irreversible effect: 'no graceful goodbye; the call just ends' and 'the caller hears the line drop.' It also states a precondition: 'Only works on calls that are currently in progress.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a front-loaded summary, then behavioral detail, then usage guidance. Every sentence earns its place—the line-drop analogy, the prerequisite, the sparing-use warning—with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema present, the description thoroughly covers purpose, prerequisites, usage context, behavioral effects, and alternatives. It is complete and standalone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only 'call_id' (string) with no description (0% coverage). The description compensates richly by explaining where the call_id comes from and its validity requirement: 'Use get_active_calls first to find the call_id of a live call.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Immediately terminate an active voice session.' It elaborates with specific behavioral detail ('Disconnects all participants instantly', 'the call just ends') and distinguishes from sibling tools by noting it only works on calls currently in progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'for emergencies, stuck calls, or when explicitly asked to end a call.' It also provides the alternative path: 'In most cases, the agent's own timeout and hangup logic will end calls naturally.' The prerequisite is clear: 'Use get_active_calls first to find the call_id of a live call.'
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:

[![neuratel-mcp MCP server](https://glama.ai/mcp/servers/Neuratel-AI/neuratel-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Neuratel-AI/neuratel-mcp)

Score Badge

Copy to your README.md:

[![neuratel-mcp MCP server](https://glama.ai/mcp/servers/Neuratel-AI/neuratel-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Neuratel-AI/neuratel-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Neuratel-AI/neuratel-mcp'

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