ctm-multi-mcp

Official

by CTMJSON

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
The list_*/get_* pairs are each clearly scoped to a distinct entity (numbers, contacts, sources, etc.). The reporting tools (call_disposition_report, call_summary_report, call_export, call_crosstab, reports_series) have overlapping call-data purposes but their descriptions clarify distinct output formats and use cases, so an agent can usually pick correctly.
Naming Consistency4/5
The dominant pattern is list_<entity> / get_<entity>, which is consistent and predictable. The reporting tools deviate with names like call_export, call_crosstab, and reports_series, which are still descriptive but don't follow a uniform verb_noun convention. Overall the set is orderly, not chaotic.
Tool Count3/5
At 32 tools, the server is on the heavy side, exceeding the 3-15 tool sweet spot. However, the count is largely justified by the need to cover 12+ entity types with list/get pairs plus several reporting tools. It's not bloated with redundant duplicates, but it does tax an agent's context window.
Completeness4/5
The server covers a wide range of call-tracking resources (calls, numbers, contacts, sources, queues, bots, menus, schedules, routes, users, tags, texts) and provides multiple reporting/export options. Minor gaps exist: no get_text, get_tag, or get_sub_account, and no mutation operations, but for a read-heavy reporting API this is largely complete.
Average 4.4/5 across 32 of 32 tools scored. Lowest: 3.6/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 status not available
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?
With no annotations, the description carries the full burden. It discloses that the full payload is returned unless fields is specified, and that field filtering is 'cheaper.' However, it does not address error cases, permissions, or rate limits, which are relevant for an API 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences with front-loaded purpose and a clear, useful tip about fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema handles return values. The description explains how to request a subset of fields, which complements the schema. It lacks guidance on alternative tools or error behavior, but for a simple getter this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description meaningfully explains the `fields` parameter's format (comma-separated keys) and its benefit. It does not elaborate on `contact_id` and `account_id`, but their names and schema types make them self-explanatory. Given 0% schema description coverage, the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full details for a specific contact, using a specific verb ('Get') and resource ('specific contact'). It doesn't explicitly distinguish from list_contacts, but the 'specific' qualifier implies a single-record lookup.
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 gives guidance on using the fields parameter to reduce payload when checking several contacts, implying the tool is for targeted lookups. It does not mention when to use list_contacts or other alternatives, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the default active-sub-account filtering and enumerates valid account_status values, which is valuable behavioral context. It also implies a read-only nature. It does not mention pagination or output format, but the output schema likely covers return structure. This exceeds a baseline given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose and efficiently organized. Every sentence adds value: the first states the main function, the second clarifies output (usage charges by date range), and the third explains default and alternate behaviors. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are covered elsewhere. The description provides essential operational context: default filtering, date-range usage, and account_status options. For a read-only query tool with no required parameters, this is largely complete. Minor gaps include lack of mention of account_ids and any permissions, but these are acceptable given the 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?
Schema description coverage is 0%, so the description must compensate. It clarifies account_status values and implies that start_date and end_date form a date range. However, the account_ids parameter is not mentioned at all. With four parameters, the coverage is partial and leaves one parameter entirely ambiguous, so the description adds some value but is not fully compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'billing/ledger data across sub-accounts', clearly indicating the tool's function. It explicitly states it shows usage charges for a date range, which adds clarity. While it doesn't explicitly contrast with siblings like account_summary, the resource focus is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on default behavior (queries active sub-accounts) and how to adjust via account_status. However, it does not mention when to use this tool over alternatives like account_summary or reports_series, nor does it provide any exclusion criteria. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses the default full-payload behavior and the field-selection option, which gives insight into performance trade-offs. However, it does not explicitly state read-only status, error behavior, or permissions, leaving some gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the main purpose, followed by a valuable tip. No wasted words or repetition of schema info.
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 get tool with an output schema, the description is mostly sufficient, but given 0% schema coverage it could provide more context about the identifiers (e.g., how queue_id is scoped by account_id) or example usage. The field-selection tip adds value, but the overall guidance feels slightly under-specified for an agent encountering it cold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful detail for the 'fields' parameter (comma-separated list, purpose) but gives no additional semantics for 'queue_id' or 'account_id' beyond their schema titles. Since schema coverage is 0%, the description partially compensates but not fully for the required identifier parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('call queue'), clearly distinguishing this from sibling list_queues. It states exactly what the tool does: returns full details for a specific queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the fields parameter ('when checking several queues in a row') and implies the tool is for retrieving a single queue. It does not explicitly mention when not to use it or alternatives, but the usage context is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a key behavioral trait: passing 'fields' returns only those fields and is 'cheaper' than the full payload. However, it does not mention error behavior, permissions, account_id semantics, or any other potential side effects. This is minimal but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main purpose is front-loaded in the first sentence, and the second sentence efficiently explains the optional fields parameter. Every clause adds value.
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 a simple get-by-ID operation with an output schema present, so the description need not detail return values. It covers the core purpose and the main behavioral variation. Some missing parameter explanations and a lack of sibling differentiation slightly reduce completeness, but it is adequate for a tool of this complexity.
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%, so the description must compensate for all parameters. It does explain 'fields' well: comma-separated list, returns just those, cheaper. However, it does not explain the required 'user_id' and 'account_id' parameters, which are only given as titles in the schema. The description fails to fully 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 begins with a specific verb and resource: 'Get full details for a specific user.' This clearly distinguishes it from sibling tools like list_users (which lists many users) and other get_* tools (which target different resource types). The resource and action are unambiguous.
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 this tool when you need details for a single user, as opposed to listing all users. It also gives practical guidance on when to use the 'fields' parameter (when only a few fields are needed). However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the default filtering and valid status values, which is useful. However, it does not explain the account_ids parameter, any permission requirements, or whether this is a read-only operation. The output schema covers return format, but other behavioral aspects remain unclear.
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, front-loaded with the core purpose, then details. Every sentence earns its place with no filler. Well-structured and 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?
For a tool with 2 optional parameters and an output schema, the description is quite complete. It explains what the summary contains, the default filter, and how to change it. The only notable gap is the lack of explanation for account_ids, but this is a minor omission given the simplicity of the tool 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.
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 adds meaning for the 'status' parameter by listing allowed values ('archived', 'canceled', 'paused', 'all'). However, 'account_ids' is not explained, though its title ('Account Ids') and optional nature are somewhat self-evident. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a high-level summary of each sub-account's configuration'. It goes on to specify the content (status, number counts, source counts, active routing objects), which distinguishes it from sibling tools that retrieve individual resources or plain lists.
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 about the default behavior (active sub-accounts only) and explicitly lists the status values to include other states. It does not explicitly name alternatives or state when not to use this tool, but the summary nature is self-evident relative to siblings like list_sub_accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the field-subsetting behavior and the 'cheaper' nature, which is useful, but it does not mention error cases, authentication needs, or explicit read-only guarantees. The term 'Get' implies read-only, but that is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, the second explains a smart usage hint. It is concise, front-loaded, and every sentence 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?
For a single-resource getter, the description covers the main purpose, the optional field filtering, and a performance consideration. Since an output schema exists, return values need no further explanation. It is missing some details about parameter roles, but overall it is complete enough for straightforward use.
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 explains the 'fields' parameter in detail (comma-separated top-level keys, subset of payload, cost efficiency), but does not clarify 'source_id' or 'account_id', though their purpose is implied by their names. The compensation is partial.
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 full details for a specific source,' which clearly identifies a single-resource retrieval operation. The verb 'get' and resource 'source' distinguish it from sibling tools like 'list_sources' and other resource-specific getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining when to use the 'fields' parameter ('when checking several sources in a row') and emphasizes the cost benefit. It does not explicitly mention alternatives or when not to use the tool, but the purpose is evident from the resource-specific naming.
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 disclosure burden. It reveals that the tool returns full details including keypress mappings, and that the 'fields' parameter can reduce the payload for cost efficiency. This adds meaningful behavior beyond what schema shows, though it doesn't mention errors, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The second block explains the optional parameter with a clear use case. Every sentence adds value, and the structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, an output schema exists to explain return values, and the description covers the main functionality and the optional field-filtering behavior. It does not mention edge cases or prerequisites, but for a straightforward get tool, the description is sufficient.
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. The 'fields' parameter is well explained as a comma-separated list of top-level keys for cheaper payloads. The other parameters (account_id, voice_menu_id) are not described, but their names make their purpose obvious. Overall, partial compensation for the missing schema 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 clearly states the tool gets full details for a specific voice menu, including keypress mappings. This is a specific verb+resource and distinguishes from list_voice_menus, which lists menus.
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 does not explicitly compare to alternatives like list_voice_menus. It does imply usage for retrieving a single menu's details, and provides guidance for using the 'fields' parameter when checking several menus, but no explicit when-to-use or 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?
Without annotations, the description carries the full burden. It discloses the behavior of the `fields` parameter (comma-separated list of top-level keys, returns subset, cheaper) which adds useful context beyond the schema. It does not mention auth or side effects, but the operation is clearly a read-only fetch by its name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose. The second sentence efficiently explains the optional parameter with a concrete example. Every word earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with an output schema available, so return values are covered. The description covers the main purpose and the only non-obvious parameter behavior. No external dependencies or edge cases are left unaddressed for this type of retrieval operation.
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 does an excellent job explaining the `fields` parameter's syntax and purpose, but gives no additional semantics for `geo_route_id` and `account_id`, which are largely self-explanatory from their names and the required 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 the verb 'Get' and the resource 'specific geo router', distinguishing it from list_geo_routes and other get_* tools. The scope is specific to retrieving details for one router identified by an ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the `fields` parameter (e.g., when checking several routes in a row), but it does not explicitly contrast this tool with the sibling `list_geo_routes` or state when to prefer one over the other. The intent is implied but not fully explicit.
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 the tool returns either the full payload or a subset via `fields`, which is a useful behavioral detail beyond the schema. It does not mention side effects or permissions, but since this is a read operation, the disclosed behavior is sufficient for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and provides a focused example. Every sentence earns its place without redundancy or unnecessary detail.
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 output schema exists (so return values are already documented) and the tool is a simple single-resource getter, the description covers the main behavioral nuance (partial payload selection). It does not mention prerequisites beyond the required parameters, but the schema already lists those. The description is complete enough for a tool of this complexity.
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%, so the description must compensate for the lack of parameter documentation. It thoroughly explains `fields` but provides no additional meaning for `number_id` or `account_id` beyond their self-evident names. This partial compensation is insufficient for a low-coverage 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 the tool retrieves 'full details for a specific tracking number,' using a specific verb and resource. It distinguishes itself from sibling get_ tools by explicitly naming the resource type (tracking number), so the agent knows exactly what this tool accesses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using the `fields` parameter to reduce payload, including a concrete use case ('when checking several numbers in a row'). However, it does not mention any alternatives or when not to use this tool, so it misses the full picture of exclusionary 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 full responsibility for behavioral disclosure. It does this well by stating the returned statistics, the default behavior of querying only active sub-accounts, and the ability to override via account_status. It omits finer details like timezone handling or pagination, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a one-line purpose, a concise list of return values, and two clear parameter usage notes. No repetitive or filler content; every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return details are not required in the description. The description covers the main filtering parameters and behavioral defaults, making the tool operable. The missing account_ids semantics is the only notable completeness 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%, so the description must compensate. It explains start_date, end_date, time_duration, and account_status with formats/examples. However, account_ids is completely omitted, leaving the agent without any guidance on how to specify which sub-accounts to include, which is a meaningful 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 opens with a specific verb+resource: 'Get aggregated call summary statistics across sub-accounts.' It clearly distinguishes this from sibling tools by emphasizing aggregation, sub-account scope, and combined totals, while also listing the specific metrics 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 provides clear usage context by explaining accepted date parameters (start_date/end_date or time_duration), including concrete examples for time_duration, and the account_status filter with its possible values. However, it does not explicitly contrast with sibling tools like call_disposition_report or call_crosstab.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does add useful context: the fields parameter returns only requested top-level keys, which is 'cheaper' — implying a smaller payload. However, it does not mention potential side effects, authentication requirements, error behavior, or rate limits, leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs: the first states the core purpose, the second gives a focused usage tip. Every sentence earns its place, and key information is front-loaded. There is no redundant or verbose wording.
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?
This is a simple read tool with an output schema, so the description does not need to explain return values. It covers the essential purpose, the time blocks detail, and an optimization for the fields parameter. Missing explicit guidance on when to choose this over list_schedules or what happens on error, but overall sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 must compensate. It does explain 'fields' with concrete semantics: a comma-separated list of top-level keys that limits the payload, with a cost/benefit note. The other parameters (schedule_id, account_id) are self-explanatory from their names, and the description adds enough value for the one non-obvious 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 opens with 'Get full details for a specific schedule, including time blocks,' which uses a specific verb ('get') and resource ('specific schedule'), clearly distinguishing it from list_schedules. It also specifies what the response includes (time blocks), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by explaining when to use the 'fields' parameter (when checking several schedules in a row) and implies the tool is for single-schedule retrieval. However, it does not explicitly mention alternatives like list_schedules or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the output is meant for the 'by' parameter, which adds useful behavioral context. However, with no annotations, it doesn't explicitly state whether this is a read-only operation or other side effects, though the 'list' verb implies it.
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 concise sentences front-load the action and immediately state the purpose. No filler or redundant information.
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 is complete. It states what is listed and how the list is used, while the output schema handles return format details.
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 zero parameters, so the baseline is 4. The description further adds meaning by explaining that the returned dimensions are values for the 'by' parameter in reports_series, which provides context beyond 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 clearly states the tool lists dimensions for reports_series, with an explicit link to the 'by' parameter. This distinguishes it from other list tools like list_sub_accounts or list_users, making the purpose immediately understandable.
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 when to use this tool (to get valid values for the 'by' parameter of reports_series). It doesn't mention exclusions or alternatives, but the usage context is clear enough for such a simple metadata tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns ('version and build info') and implies a read-only, non-destructive operation, but does not explicitly mention that it has no side effects or require any special permissions. For a simple info tool this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose and context without any filler. It is front-loaded with the action and resource, making it highly scannable and 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?
For a parameterless tool with an output schema, the description fully covers the essential context: what the tool does and why an agent would use it. There is no missing information about parameters or return shape, as the output schema handles the latter.
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 does not need to explain parameter details. The baseline of 4 applies, and the description correctly focuses on the tool's purpose rather than inventing parameter-related content.
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 'Return' and identifies the resource 'server version and build info', making the tool's purpose immediately clear. It is unique among the listed sibling tools, all of which focus on data listing/retrieval rather than system info.
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 'to confirm which code is live' provides clear context for when this tool is appropriate. No alternatives or exclusions are needed given the tool's singular, self-contained purpose, and the context is sufficient for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It transparently describes the two response modes (full payload vs selected fields) and the cost-saving intent, though it omits auth and error 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?
Three sentences, front-loaded with the primary purpose, followed by focused parameter guidance. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-format details are unnecessary. The description covers the tool's purpose and the main optional behavior; only minor error/edge-case guidance is missing, but the overall context is sufficient for this simple 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?
Schema has 0% description coverage. The description compensates for the fields parameter by specifying comma-separated top-level keys and a practical use case. voice_bot_id and account_id remain self-explanatory from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets full details for a specific voice bot, including prompt and config. The verb 'get' plus 'specific' distinguishes it from sibling tools like list_voice_bots and other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on using the optional fields parameter for cheaper, partial responses when checking several bots. It does not explicitly mention alternatives like list_voice_bots, but the usage context is 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 thoroughly explains pagination (CTM caps per_page at ~100, auto-walking pages), truncation warnings, and default status filtering. This goes well beyond a basic 'lists routes' statement and gives the agent essential execution expectations.
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 paragraph breaks, front-loaded purpose, and every sentence adds useful information. It is long but justified by the behavior it discloses; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 optional params, no annotations) and the presence of an output schema, the description covers the most critical behavior: pagination, truncation, status defaults, and account-level iteration. It falls short only on explicit parameter documentation for account_ids, though the output schema mitigates return-value ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates partially by explaining max_items (raise for large accounts), status (allowed values and default), and per_page (indirectly via CTM cap). However, it does not explicitly explain account_ids semantics, which is a notable gap for a multi-account listing 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 'List geo routers and conditional routers across sub-accounts,' using a specific verb and resource while distinguishing this list operation from the sibling get_geo_route tool. It also clarifies scope (sub-accounts) and includes both geo routers and conditional routers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it explains default behavior (active sub-accounts only), how to include other statuses, and how to adjust max_items for large accounts. However, it does not explicitly contrast with alternatives like get_geo_route, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description carries the full transparency burden. It discloses the automatic paging behavior, the per_page cap, the truncation warning, and the distinction between account_status and status. This is meaningful behavioral information beyond what the schema provides, though it stops short of covering error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear first sentence states the purpose, followed by concise details on output, paging, and filtering. Every sentence adds value and there is no filler. It is neither too terse nor overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, some nuanced interactions) and the existence of an output schema, the description covers the most important behavioral aspects: paging, truncation, and account filtering. It does not explain account_ids or name_contains in detail, but these are relatively simple. The description is sufficiently complete for an agent to select and invoke the tool correctly in most cases.
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 must clarify parameters. It explains max_items (paging quantity), per_page (indirectly via cap), account_status (which accounts to search), status (filters numbers by their own status), and number_type (toll-free/local). It does not explicitly cover account_ids or name_contains, but the key parameters are well-defined.
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 it lists tracking numbers and their routing across sub-accounts, immediately distinguishing it from sibling tools like get_number (single number) and list_sub_accounts (different resource). The verb 'list' plus detailed resource and scope makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: it explains the default active sub-account filtering, how to override with account_status, and the meaning of max_items for paging. It does not explicitly name alternative tools or state when not to use this tool, but the usage context is strong.
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 transparency burden. It discloses automatic pagination, the CTM per_page cap, max_items truncation behavior, and the default status filter, going well beyond a typical 'list' tool 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 concise yet information-dense, with a clear front-loaded purpose and follow-up paragraphs that each add operational value. There is no wasted text or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values need not be described. The description covers pagination, defaults, and truncation. However, account_ids is left unexplained, which is a small but notable gap for a tool with four parameters and no schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains status values and defaults, max_items semantics, and per_page cap indirectly. However, the account_ids parameter is not described, and schema description coverage is 0%, so the description only partially compensates for the missing schema metadata.
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 a clearly identified resource ('call queues' with synonyms 'ring groups, agent pools'), scoped to 'across sub-accounts'. This distinguishes it from sibling tools like get_queue (singular resource) and list_sub_accounts (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it lists queues across sub-accounts, defaults to active sub-accounts only, and tells the user how to include other statuses. It does not explicitly contrast with get_queue or other alternatives, but the usage context is clear enough.
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 discloses behavior: it explains automatic paging due to CTM's per_page cap, the truncation warning when max_items is exceeded, and the default filtering to active sub-accounts. These details go well beyond the schema and are essential for correct invocation.
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 yet information-dense: three sentences cover purpose, paging behavior, and status parameter. Every sentence earns its place, and the most critical 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?
For a listing tool with no annotations, the description provides robust operational details: paging, truncation, default filtering, and parameter guidance. The output schema handles return-value documentation. The only notable gap is the lack of account_ids semantics, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description adds meaning for max_items (raising it for large lists), status (accepted values), and per_page (context about CTM's cap). However, account_ids is omitted entirely, leaving its purpose and format unspecified. The description partially compensates for the schema gap but does not cover all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List tracking sources (channels, campaigns) across sub-accounts,' which specifies a clear verb, resource, and scope. It distinguishes itself from siblings like get_source (which retrieves a single source) and list_sub_accounts (which lists accounts).
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 operational context: it explains the default behavior (active sub-accounts), how to change the status filter, and when to increase max_items for large source lists. It does not explicitly name alternative tools, but the scope is clear enough that an agent would know when to invoke this versus a get_* or report 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, the description carries full burden and does so well: it discloses automatic pagination, the per_page ceiling (~100), the truncation-warning behavior, and the default status filter. This gives the agent concrete expectations for side effects and limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short paragraphs, front-loaded with purpose, then behavior, then defaults/status. No redundant phrases; every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong for a list tool: it covers pagination, limits, warnings, and statuses, and an output schema exists to define return shape. The main omission is account_ids semantics, which makes it not fully complete for the 4-parameter 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 coverage is 0%, so the description must explain parameters. It meaningfully explains status values, max_items truncation, and per_page cap, but it never explains the account_ids parameter (format, filtering behavior, relationship to 'across sub-accounts'), leaving a gap 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 and resource ('List VoiceAI voice bots across sub-accounts'), making the tool's scope immediately clear. It is distinct from sibling tools like get_voice_bot (single bot retrieval) and list_voice_menus (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes the default active-sub-account scope and lists valid status override values ('archived', 'canceled', 'paused', 'all'), and frames when to raise max_items. However, it doesn't explicitly name alternatives like get_voice_bot for singleton lookups, so it stops short of a full when/when-not guide.
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 available, the description carries the full burden of behavioral disclosure. It reveals the non-obvious large default payload (~100+ fields) and explains how the 'fields' parameter truncates the response, which is critical operational knowledge. It does not mention permissions or error handling, but these are not prominent concerns 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 moderately sized but front-loads the primary purpose. Each sentence delivers operational value—large payload warning, field-filtering optimization, and alternative tool referral—without redundancy. It could be slightly tightened, but the structure is logical and scannable.
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?
With an output schema present, return shape is already documented. The description covers the main contextual concerns: default response size, parameter filtering behavior, and alternative tool selection. It does not detail error cases or authentication, but these are not major gaps for a straightforward single-call retrieval tool with an output schema.
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 provides only names and types with 0% description coverage. The description compensates by thoroughly explaining the 'fields' parameter, including comma-separated format and examples of valid top-level keys. The required call_id and account_id are self-evident identifiers from the tool name, so the description adds sufficient semantic value for the most complex 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 opens with a specific verb and resource ('Get details for a specific call'), clearly indicating single-record retrieval. It also differentiates from the sibling call_disposition_report by explicitly directing bulk analysis elsewhere, establishing its scope as individual call detail access.
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 advises using call_disposition_report for bulk disposition analysis, providing a clear alternative and exclusion condition. It also gives practical usage tips (pass 'fields' to reduce payload when checking several calls), giving the agent concrete guidance on when and how to use the tool.
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 full burden. It discloses a known limitation (intermittent empty responses), explains that debug envelope keys are included when items=0, and compares server-side vs client-side behavior. This exceeds typical disclosure, though it doesn't mention auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (Required, Optional filters, Known limitation) and front-loads the main action. It's longer than average but each sentence adds operational value, and there's no repetition 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?
For a complex 19-parameter tool with no annotations, the description covers the core functionality, required parameters, optional filters, operators, debugging behavior, and fallback. The output schema exists, so return-value documentation isn't necessary. Minor omissions like auth/rate limits keep it from a 5.
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 compensates by grouping the 19 parameters into required, optional filters, and operators. It explains the by dimension (referring to reports_series_dimensions), interval granularity, and lists all operators. However, it doesn't individually describe account_ids/account_status, which are less self-evident.
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+scope: 'Get time-series call data aggregated by dimension across sub-accounts.' It further distinguishes itself from siblings by calling it 'the most flexible reporting endpoint' and explicitly mentions a fallback to call_disposition_report, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states required parameters (start_date, end_date, by, interval) and provides explicit guidance on when to use an alternative: 'fall back to call_disposition_report... works reliably.' This gives the agent concrete conditions for use versus a specific sibling 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 key behaviors: automatic paging, the CTM per_page cap, max_items truncation with a warning, defaulting to active sub-accounts, and allowed status values. This goes well beyond a basic list operation and gives the agent a solid understanding of side effects and limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clear, purposeful sections: purpose, filters, pagination behavior, and status defaults. Every sentence adds value without fluff, making it concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no annotations, the description is quite comprehensive, covering filters, pagination, truncation, and status handling. The output schema exists, so return values are already covered. The only notable omission is the account_ids parameter, which prevents a perfect score.
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 has 0% description coverage, so the description must compensate. It explains the name, email, and phone filters, the per_page and max_items usage, and the status enum values. However, it does not explicitly describe the account_ids parameter, leaving a minor gap in an otherwise strong compensatory effort.
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 'List contacts across sub-accounts,' which uses a specific verb (List), defines the resource (contacts), and clarifies the scope (across sub-accounts). This clearly distinguishes it from siblings like get_contact (single contact) and list_sub_accounts (accounts).
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 filtering (name, email, phone), pagination behavior, and status defaults. It explains how to adjust scope with status values, but it does not explicitly discuss when to use this tool versus alternatives like get_contact. This aligns with 'clear context, no exclusions,' meriting 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?
No annotations are provided, so the description carries the burden. It discloses the default active filter, valid statuses, and the return fields (account IDs, names, statuses, labels). This goes beyond basic metadata, though it omits potential pagination or permission details. Still, it provides solid transparency for a read-only 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 three short paragraphs, front-loaded with purpose, followed by parameter behavior and return details. Every sentence adds information, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter, an output schema (so return format is separately defined), and a thorough explanation of status filtering, the description covers all necessary operational aspects. It is complete for the tool's simplicity.
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 describes 'status' only as an optional string/null with no enum or description. The description compensates fully by enumerating valid statuses and explaining the default behavior, making parameter usage clear.
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 sub-accounts accessible by the parent API key', using a specific verb and resource. It clearly distinguishes this from other list_* tools by focusing on sub-accounts and the parent API key context.
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 explains the default behavior (active only) and the status parameter options ('archived', 'canceled', 'paused', 'all'), giving clear context for when to use. However, it does not explicitly name alternative tools or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals pagination behavior (auto-walking pages due to CTM cap), the role of max_items, truncation warnings, and default status filtering. These are meaningful behavioral traits beyond the bare 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 front-loaded with the main purpose, then adds contextual use, then dives into parameter behavior. Every sentence provides distinct value, and the formatting with dashes and semicolons keeps it readable without being bloated.
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 output schema exists, return format doesn't need explanation. The description covers the most important operational details: pagination, status filtering, truncation, and capacity. The only missing piece is explicit handling of account_ids and date formats, which are secondary for a list operation.
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 max_items, per_page cap, status values, and suggests using date ranges. However, it does not describe account_ids or date format details, leaving a small gap in an otherwise parameter-aware 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 and resource: 'List SMS/text messages across sub-accounts.' This clearly distinguishes it from sibling tools like list_calls or list_numbers, and the scope (across sub-accounts) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case: 'Useful for auditing text communication across all client accounts.' It also advises on parameter tuning (raise max_items or narrow dates). However, it does not explicitly mention alternative tools or when not to use it, so it stops short of full 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 carries full responsibility. It discloses pagination behavior (auto-paging, CTM per_page cap ~100), the truncation warning for large lists, and the default status filter. This is rich behavioral context 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 compact and well-structured: a one-sentence definition followed by essential details in separate focused paragraphs. Every sentence adds value, 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?
Given the tool's complexity (pagination, status defaults, multi-account scope) and the presence of an output schema, the description covers most key aspects well. The omission of account_ids is a slight gap, but overall it is sufficiently complete for an agent to use effectively.
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 explain parameters. It does explain max_items, per_page, and status with practical meaning (e.g., 'raise max_items for accounts with a large user list'). However, account_ids is not mentioned, leaving one of four parameters undocumented.
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 users (agents, admins) across sub-accounts,' which clearly identifies the action, resource, and scope. This distinguishes it from sibling tools like get_user (single user) and list_sub_accounts (sub-accounts themselves).
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 concrete usage guidance: defaults to active sub-accounts, how to include archived/canceled/paused via status, and when to raise max_items for large lists. It does not explicitly name alternatives, but the context for when to use this tool is 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 fully carries the transparency burden. It explains paging behavior (walks as many pages as needed due to CTM's per_page cap), truncation warning when max_items is exceeded, and the default of active sub-accounts only. This is rich behavioral context beyond what the schema shows.
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. The first sentence gives the core purpose, and the subsequent sentences add necessary detail on pagination, limits, and status filtering. Every sentence provides value, 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?
The description covers all essential behaviors for a list tool: paging, limits, status filtering, and truncation warnings. Combined with the presence of an output schema, it is largely complete. The main gap is the lack of explicit detail on the account_ids parameter format, but this is a minor omission given the overall clarity.
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 does well for status (lists valid values and default) and max_items (explains its purpose and when to increase it). It also clarifies per_page in the context of paging. However, account_ids is not explicitly explained beyond the phrase 'across sub-accounts', leaving its format or filtering behavior ambiguous.
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 exact function: 'List IVR voice menus across sub-accounts.' This uses a specific verb (list), a specific resource (IVR voice menus), and a scope (across sub-accounts), which distinguishes it from siblings like list_voice_bots or get_voice_menu.
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 operational guidance, such as raising max_items for accounts with many menus and passing status values to include archived/canceled/paused menus. It implies when to use this tool (listing across sub-accounts) but does not explicitly call out alternatives like get_voice_menu for a single menu, so it misses a clear exclusion.
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 important behavior: automatic paging with per_page capped at ~100 by CTM, truncation warnings when max_items is exceeded, and default sub-account status filtering. These details go beyond the schema and help the agent set correct expectations.
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 structured into three short paragraphs, each adding essential information: a clear definition, pagination and truncation behavior, and defaults for sub-account status. No wasted sentences; the length is appropriate for the tool's complexity.
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 4-parameter schema, zero annotations, and presence of an output schema, the description covers the key behavioral aspects: pagination strategy, truncation handling, status filtering, and account scope. The return shape is presumably covered by the output schema, so not describing it does not harm completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'status' values, the 'max_items' behavior with truncation warnings, and the per_page cap. However, 'account_ids' is only implied via 'across sub-accounts' and is not explicitly described, leaving a minor 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: 'List tags (labels) across sub-accounts.' This clearly identifies the tool's function and distinguishes it from sibling tools like list_numbers or list_contacts by emphasizing the cross-account scope and the tagged entity types (calls, contacts, numbers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it defaults to active sub-accounts, explains how to include archived/canceled/paused accounts via the 'status' parameter, and describes when to raise 'max_items' for large tag counts. It does not explicitly name alternative tools, but no sibling provides tag-specific listing, so this is acceptable.
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 discloses the tool's behavior: it fetches calls, returns a matrix, includes live calls by default, lets users exclude in-progress calls via exclude_status, and explains the caveat about paid attribution data and Google withholdings. This goes well beyond minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical but each sentence adds useful context, from the high-level purpose to specific dimension nuances and the 'in progress' behavior. It is front-loaded with the main purpose, though the dimension list and caveats add length that could overwhelm if read in full.
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 9 parameters, no annotations, and an output schema, the description addresses nearly every operational aspect: how to filter, what the matrix layout is, which dimensions exist, data attribution caveats, and handling of live calls. It is thorough enough to guide effective use without further documentation.
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?
Although schema coverage is 0%, the description compensates by explaining account_ids, date range (start_date/end_date or time_duration), max_calls, exclude_status, and rows/cols defaults and allowed values. However, it does not explain the account_status parameter or the expected format for account_ids (e.g., comma-separated vs. repeated), leaving a minor 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 opening sentence 'Build a source × status crosstab matrix across sub-accounts' uses a specific verb and resource, and the description expands on the output format and intended use case. It clearly distinguishes from siblings like call_disposition_report by framing this as a single-call aggregation across sub-accounts.
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 it's designed for a specific question ('break down call volume by source and status for accounts X, Y, Z this week') and contrasts with 'fanning out multiple filtered disposition reports.' It also provides concrete guidance on date formats, max_calls, and exclude_status, covering when to use each.
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 pagination behavior (auto-walks pages, CTM caps per_page at ~100), the truncation warning, max_items semantics, and default filtering. This goes beyond the input schema and provides essential operational 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 compact yet information-dense. It front-loads the core purpose in the first line, then provides need-to-know behavioral details in a structured, skimmable format. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (paging, status filtering, multi-account scope) and complete lack of annotations, the description covers almost everything needed to invoke it correctly. The output-schema exists, so return values are handled structurally. A small gap is not documenting the exact format of account_ids, but overall the contextual need is met.
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 explicitly explains status (possible values and effect) and max_items (raises limit, triggers truncation warning). It does not detail account_ids format or per_page beyond mentioning the CTM cap, but it meaningfully covers two key parameters and the overall paging model, which is the critical semantic 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 opens with a specific verb+resource: 'List time-based schedules across sub-accounts.' It clearly identifies the tool's function and scope, and later differentiates it from the sibling get_schedule by referencing 'time-based schedules' and 'routing rules' activity windows. This makes the purpose unambiguous and distinct.
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 usage guidance: 'Defaults to active sub-accounts only. Pass status="archived", "canceled", "paused", or "all" to include others.' It also explains when to raise max_items for larger accounts. While it doesn't explicitly name alternative sibling tools, it clarifies its own scope and behavior sufficiently for selection among the siblings.
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: it queries only active sub-accounts by default, paginates concurrently server-side, applies status/source filtering client-side because the API's status filter is unreliable, and explains caveats like Google withholding keyword-level data. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each sentence earns its place. It is front-loaded with the primary purpose and organized into clear paragraphs for caveats, duration scoping, and client-side filtering. 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?
Despite having 10 parameters, no annotations, and no schema descriptions, the description covers return values, edge cases (e.g., '(not provided)' keywords), filtering behavior, and alternatives. It is a complete usage guide that leaves little ambiguity for the agent.
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 must compensate. It meaningfully explains account_status, min_duration/max_duration, status, and source semantics. However, not all 10 parameters are explicitly addressed (e.g., top_n, max_calls, account_ids, start_date/end_date), though some are inferable from context. It still adds significant value 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 opens with 'Aggregate call outcomes/dispositions across sub-accounts in one call' — a specific verb+resource+scope. It clearly distinguishes itself from sibling tools like search_calls and get_call, which retrieve raw records rather than aggregated reports.
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: 'Use this instead of paging through search_calls or looping get_call — this is the tool to reach for when asked to analyze calls/dispositions over a date range.' It also names an alternative (call_crosstab) for campaign grouping, providing both when-to-use and when-to-avoid 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 present, the description fully discloses the tool's behavior: it returns raw CSV text with a header row, applies filters client-side after fetching the entire bounded set, includes a truncation warning as a leading comment if max_calls is hit, and uses server-side pagination through the same mechanism as call_disposition_report. It also warns about the unfiltered count in search_calls output, which is important for interpreting results.
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 front-loaded: it opens with a clear one-sentence purpose, then organizes information into paragraphs for alternatives, filters, fields, sort, dates, and return value. Every paragraph adds essential behavioral or usage detail, and the structure (with explicit 'Filters', 'fields:', 'sort:' labels) 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 complex 12-parameter tool with no annotations, this description is exceptionally complete: it covers the return format, edge cases (truncation warning), cross-tool sanity checks (call_disposition_report), and the exact list of supported fields. It even explains the pitfalls of using sibling tools, which helps an agent avoid misuse.
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 has zero parameter descriptions, so the description is critical. It meticulously documents most parameters: filters (min/max_duration, status, source), fields (with a full supported list and semantics), sort (with allowed keys and default), date/time selectors (start_date/end_date or time_duration), and max_calls (with the cap behavior). However, account_ids and account_status are not explicitly explained, leaving a small gap despite the otherwise thorough 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 first sentence clearly states the tool exports a filtered, row-level list of calls as CSV, naming the specific verb and output format. It explicitly differentiates from siblings by saying 'not search_calls, not a get_call loop', and clarifies the use case with examples.
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 extensive guidance: it tells the agent to use this tool when raw call records matching a filter are needed, and explicitly names two tempting alternatives (search_calls and get_call) that are worse. It explains why those alternatives fail (per-page filtering and per-call loops) and even gives example queries, making the when-to-use decision 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 fully discloses behavioral quirks: server-side filtering is unreliable for status so client-side filtering is best-effort and page-limited; only active sub-accounts are searched by default; campaign/keyword may be blank for non-paid or withheld by Google. These are critical non-obvious behaviors.
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 sentence contributes essential guidance. It is well-structured into focused paragraphs (scope, pagination, filtering limitation, alternative tools), and the content density justifies the length. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex search tool with 16 optional parameters, no annotations, and no schema descriptions, this description covers almost everything an agent needs: result contents, filtering limitations, expected blanks, pagination, and when to use sibling tools. The presence of an output schema means return-value details are not required here.
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?
Although the schema has zero descriptions for its 16 parameters, the description adds significant meaning for key ones: account_ids, account_status, page/per_page, status/disposition, and date ranges. However, some parameters like sort, user_id, queue_id, and tracking_number_id are not explicitly explained, so coverage is not complete.
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: 'Search calls across sub-accounts' and expands on the specific result fields (call_status/dial_status, disposition, source, tags, campaign/keyword) that distinguish it from siblings like get_call and call_export. This makes the tool's role 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?
Excellent guidance: it explicitly recommends call_disposition_report for accurate aggregate counts, call_export for row-level lists, and notes that per-call outcome/ad attribution is already present so there is no need to call get_call afterward. It also explains account_status options and pagination strategy.
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:

[![ctm-multi-mcp MCP server](https://glama.ai/mcp/servers/CTMJSON/ctm-multi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/CTMJSON/ctm-multi-mcp)

Score Badge

Copy to your README.md:

[![ctm-multi-mcp MCP server](https://glama.ai/mcp/servers/CTMJSON/ctm-multi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/CTMJSON/ctm-multi-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/CTMJSON/ctm-multi-mcp'

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