Aircall MCP Server

Server Quality Checklist

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

Latest release: v2.0.1
Disambiguation4/5
Most tools have clearly distinct purposes, but a few pairs like aircall_send_message vs aircall_send_agent_message and aircall_start_call vs aircall_dial could be confused. Descriptions are specific enough to guide selection, making errors unlikely.
Naming Consistency4/5
All tools share the aircall_ prefix and mostly follow a verb_noun snake_case pattern. Minor inconsistencies like aircall_remove_campaign_number (singular) vs aircall_add_campaign_numbers (plural) and standalone verbs like aircall_dial and aircall_ping keep it from being perfect.
Tool Count1/5
With 83 tools, this far exceeds the 50+ threshold for extreme count. Even for a comprehensive API wrapper, this is an overwhelming number that reduces coherence and increases cognitive load for agents.
Completeness4/5
The tool set covers the major Aircall domains comprehensively: calls, contacts, users, teams, numbers, tags, campaigns, messaging, webhooks, and integration. Minor gaps exist, such as no way to remove tags from a call or list agent message conversations, but core workflows are fully supported.
Average 3.8/5 across 83 of 83 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on August 10, 2026
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutation. The description adds no behavioral context beyond the annotation, such as partial update semantics or permission requirements, which is necessary for this destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, making it efficient. However, it omits useful context that would justify a longer description, so it is concise but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, one required, and a destructive annotation. The description only says 'update profile information' without explaining return values, partial vs. full update behavior, or any side effects. This is insufficient for an AI agent to safely and correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents all 5 parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional meaning to the parameters, merely repeating 'profile information' without elaborating on the parameters' roles or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' and identifies the resource as 'a user's profile information,' clearly distinguishing it from other user-related tools like create or delete. However, it lacks explicit differentiation from other 'update' tools for different resources, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or specific scenarios. The one-line description is purely a statement of action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag the tool as destructive (destructiveHint=true). The description adds minimal behavioral context—it doesn't clarify whether the update is partial or a full replacement, or if it affects call routing. No contradiction exists, but the description relies entirely on annotations for safety-critical information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that directly states the action and subject with a clear verb and resource. No unnecessary words, making it highly concise and front-loaded.
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 update tool with a well-documented schema and annotations, the description is adequate but has clear gaps: it lacks usage context and details about mutation semantics (e.g., partial vs. full update). The destructiveHint annotation raises the importance of clarifying behavior, which the description does not do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters, so the baseline is 3. The description mentions three parameters (name, timezone, priority) but adds no additional meaning beyond the schema; number_id is not mentioned in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a phone number's configuration, with examples of specific fields (name, timezone, priority). However, it does not explicitly differentiate from the sibling tool aircall_update_phone, so while the purpose is clear, sibling differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as aircall_update_phone or aircall_get_number. The intended usage is implied by the name and description but not explicitly stated, and there are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=false and destructiveHint=false, so the description's 'Create' aligns with those. However, the description adds little beyond that—no mention of validation, side effects, or response behavior. It is not contradictory, but fails to enrich the behavioral picture.
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, succinct sentence that immediately states the action and subject. It is front-loaded with the verb 'Create' and contains no filler words or redundant information—every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema) the description is minimally adequate. However, it omits useful context like the requirement that events must be chosen from the allowed enum (though the schema lists them) or that the URL should be publicly accessible. It is neither grossly incomplete nor thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both url and events have descriptions). The description's 'at a URL' simply restates the schema's url description, and it adds no additional semantics for the events array beyond what the schema provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new webhook' with its purpose ('to receive real-time event notifications at a URL'). It is specific and unambiguous, though it does not explicitly distinguish itself from sibling webhook tools like update or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., update_webhook, delete_webhook). It only states what the tool does, leaving the agent to infer usage context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, non-destructive operation. The description adds no additional behavioral details beyond the basic mutation — it does not mention idempotency, handling of duplicate tags, or prerequisites like existing tag IDs. It offers no context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first is action-oriented and front-loaded with the verb, the second provides brief rationale. There is no filler, 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 tool's simplicity (two parameters, no output schema, no nested objects) and the comprehensive schema and annotations, the description is largely sufficient. It could mention that tag IDs must already exist, but the low complexity means this omission is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (call_id and tags array) with clear descriptions. The tool description adds no extra parameter-level semantics, but with 100% schema coverage, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add tags') and the resource ('to a call'), distinguishing it from tag creation tools like aircall_create_tag and from other call modification tools. The verb and object are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as aircall_create_tag (for creating new tags) or aircall_list_tags (for viewing existing tags). The benefit statement is general and does not introduce usage conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, so the description need not restate safety. It adds the vague phrase 'detailed information' but does not specify return structure, error behavior, or required permissions. This is minimal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one parameter, no output schema, and clear annotations. The description states that detailed tag information is returned, which is adequate for a low-complexity read operation, though it could specify the exact output shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter tag_id, which already has a clear description. The tool description adds no additional semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get') and resource ('a specific tag'), distinguishing it from a list-all-tags operation. However, it does not explicitly mention retrieval by ID or contrast with sibling functions like aircall_list_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It lacks any mention of prerequisites (having a tag_id) or exclusion of list/create/update/delete operations, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals this is a safe read operation, and the description does not contradict that. However, the description adds no additional behavioral context beyond the literal operation—no mention of what 'key topics' looks like, whether the output is a list, or any limitations. It remains consistent but shallow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant content. It communicates the essential purpose entirely, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is quite complete: it names the resource (call) and the result (key topics). While it doesn't detail the return format, the low complexity and existing annotations make this acceptable, though a brief note about output type could push it to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter call_id described as 'The call ID'. The description adds no new parameter information, but given the schema is self-explanatory, the baseline of 3 is appropriate. No gaps to compensate for.
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 'Get key topics discussed during a call' uses a specific verb ('get') and resource ('topics'), making the primary purpose clear. It is distinguishable from sibling tools like get_sentiments and get_action_items by the 'topics' focus, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, preconditions, or related tools such as get_sentiments or get_custom_summary. The description only states what it does without contextualizing its use case relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already state. While destructiveHint=true is present, the description does not disclose effects like whether other fields are overwritten, whether updates are partial, or if confirmation is needed. It merely restates the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff, making it easy to understand. However, it is minimal and could include a bit more context without becoming verbose, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, complete schema, and annotations, the description is adequate but not complete. It lacks usage guidance and any note about how updates interact with existing data. It is enough to understand the core function but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all four parameters (100% coverage), so the description carries no additional parameter meaning. This meets the baseline of 3; the description adds nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing tag' clearly identifies the action (update) and resource (tag), with 'existing' distinguishing it from creation tools like create_tag. It is specific and unambiguous, differentiating it from sibling tools that handle tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing tag, but it does not explicitly state when to use it over alternatives or mention exclusions. There is no reference to create_tag/delete_tag or guidance on prerequisites, such as the tag already existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. It states what the tool does but does not disclose any side effects, prerequisites, or whether the operation is idempotent. With readOnlyHint=false and destructiveHint=false, the annotations already convey that it is a non-destructive write, but the description does not enrich this further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized for a zero-parameter tool and front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, empty input schema, and absence of an output schema, the description is mostly complete but lacks details on what happens after enabling, such as confirmation or side effects. It is sufficient for a basic action but does not fully inform the agent about the integration's state or expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema provides no parameter information to elaborate on. The description adds the context that the operation uses the 'current API credentials', which is useful implicit context. With no parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (enable) and the resource (integration), and specifically ties it to the current API credentials. This distinguishes it from the sibling tools get_integration and disable_integration, providing a clear, specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention that this is used when the integration is disabled, nor does it reference get_integration for checking status or disable_integration for the opposite action. The usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the safety profile is known. The description adds no extra behavioral context such as irreversibility, permission requirements, or whether the user account is deleted. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description does not address outcomes beyond the removal (e.g., does the user remain active, what happens to memberships) and does not explain the return behavior given there is no output schema. It is minimally sufficient but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for team_id and user_id. The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a user from a team' clearly states the action (remove) on a specific resource (user from a team). It distinguishes itself from siblings like add_user_to_team (opposite operation) and delete_user (permanent deletion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not clarify that this only removes membership without deleting the user, nor does it reference the inverse operation add_user_to_team or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds value by noting the direct-send behavior (bypassing the Inbox) and the messaging configuration requirement, but it does not disclose other behavioral aspects such as side effects (e.g., costs, delivery guarantees) or return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant information. It front-loads the main action and immediately provides a key distinction (bypassing the Inbox) and a prerequisite.
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?
There is no output schema, and the description does not explain what the tool returns (e.g., success status, message ID). It also omits potential side effects. However, it does cover the essential usage context and prerequisite, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, including the requirement that number_id must have messaging enabled. The description itself adds no parameter-specific details, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Send an SMS/MMS') and the resource ('from an Aircall number'). It adds the qualifier 'bypassing the Aircall Inbox,' which helps distinguish it from sending through the inbox, though it does not explicitly name alternative sibling tools like aircall_send_agent_message.
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 context for when to use this tool ('bypassing the Aircall Inbox') and a prerequisite ('The number must have messaging configured'), but it does not explicitly state when not to use it or name alternatives. The 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, which covers mutation safety. The description adds no behavioral context beyond the schema, such as partial update semantics, error behavior if the contact does not exist, or whether all fields are overwritten. It merely restates the obvious 'update' action without extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately conveys the tool's purpose. There is no redundancy or wasted words, and it is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward update tool, the description and schema cover the basic context. However, there is no mention of return values, permission requirements, or whether only provided fields are updated. Given the absence of an output schema, the description could have provided more operational context but is adequate for a simple CRUD 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 100% for all 5 parameters, each with a clear description. The description phrase 'basic information' vaguely maps to the fields but adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing contact's basic information' clearly states the action (update) and resource (contact), using a specific verb. It distinguishes from sibling tools like create_contact, delete_contact, and sub-resource updates (update_phone, update_email) by specifying 'existing contact' and 'basic information'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to update contact details, but it does not explicitly mention when to use it over alternatives like update_phone or update_email. There are no exclusions or when-not-to-use cases provided, so guidance is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, signaling a mutating operation. The description adds no extra behavioral context beyond 'update': it doesn't clarify whether both label and value can be updated together, whether it's a partial update if only one field is provided, or what happens if the phone_id doesn't belong to the contact. Since the description overlaps with annotations without adding value, the score is low.
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, short sentence that immediately conveys the tool's purpose. There is no redundant or filler content; every word contributes meaning. This is an example of ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a seemingly simple update tool with 4 parameters, 2 required, and a clear schema, the description is minimally viable. However, it lacks mention of partial-update semantics (only label or only value), potential failure modes, or guidance for distinguishing from aircall_update_number other than 'on a contact.' While annotations and schema cover some details, the description could be more complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (label, value, phone_id, contact_id) already documented in the input schema. The description does not add any parameter-specific details beyond stating that it updates a phone number, which is consistent with the schema. With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a phone number on a contact' clearly states the specific action (update) and resource (phone number on a contact), which distinguishes it from sibling tools like aircall_add_phone and aircall_delete_phone. The phrase 'on a contact' differentiates it from aircall_update_number, which likely updates a phone number at the company level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need to modify an existing phone number associated with a contact—but provides no explicit guidance on when to use alternatives like add_phone for new numbers or delete_phone for removal. No prerequisites (e.g., contact and phone must exist) or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is known. The description adds the 'existing contact' constraint, which is useful. However, it does not disclose behavior around duplicate emails, error cases, or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and free of redundancy. It is appropriately sized for a simple tool, containing exactly the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple operation with full parameter documentation and annotations, the description adequately covers purpose and scope. No output schema exists, so return values need not be explained. Minor additional context (e.g., success response) could be added, but it's not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (label, value, contact_id). The description's wording roughly maps to these parameters but adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') with a clear resource ('an email address to an existing contact'). It distinguishes from sibling tools like aircall_update_email and aircall_delete_email by stating the exact action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of exclusions, such as 'for updating an existing email, use aircall_update_email'. The phrase 'existing contact' implies a prerequisite but does not provide explicit usage context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already flags destructive behavior, and the description adds the crucial detail that the action cannot be undone. This goes beyond the structured annotation by warning about irreversibility, though it does not mention cascade effects or permissions.
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 short sentences, each with clear value: the action and an important warning. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers purpose and a key behavioral warning. It could arguably mention effects on related data (e.g., phone numbers), but the existing text is adequate for typical 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 coverage is 100% with a clear description of contact_id. The tool description does not add any parameter-level meaning, but the schema already fully documents the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a contact') with a specific resource, making the purpose unambiguous. While the name already conveys this, the description does not explicitly differentiate from sibling delete tools (e.g., delete_campaign), but the resource is clear. No misleading information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as aircall_update_contact or aircall_get_contact. The description only states the action and an irreversibility warning, offering no context on selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, so the destructive nature is known. The description does not add extra context beyond what annotations provide, such as irreversibility, permissions required, or cascading effects. It is consistent with annotations and adds minimal behavioral detail, so a neutral score is warranted.
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, compact sentence: 'Delete a phone number from a contact.' It is front-loaded with the main verb and contains no unnecessary words or fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation with a destructiveHint annotation and full schema coverage, the description is adequately complete. It clearly states the purpose and the relationship between the parameters. It does not explain what happens if the phone number is not found or if it is the last number, but that is not essential for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters ('The phone number ID to delete' and 'The contact ID'), covering 100% of schema properties. The tool description adds relational context ('from a contact') which slightly reinforces the link between parameters, but it does not significantly clarify anything beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the target ('a phone number'), and the context ('from a contact'), making it easy to distinguish from sibling tools like aircall_delete_contact or aircall_delete_email. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention, for example, that deleting a contact's last phone number might have side effects, or that aircall_delete_contact should be used to remove an entire contact. This is a basic operation with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that action items are AI-detected, but does not disclose return format, pagination, or any behavioral peculiarities. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose without 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?
Given the tool's low complexity (one parameter, no output schema, no nested objects), the description is nearly complete for basic use. It fails to clarify what 'action items' are or what the response looks like, but this is a minor gap for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single call_id parameter, with the description 'The call ID.' The tool description adds no extra semantics beyond reiterating the call context, so it aligns with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'AI-detected action items from a call,' with a specific verb and resource. This distinguishes it from sibling tools like get_summary or get_sentiments, all of which have different focus areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states the basic function without any contextual cues, exclusions, or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true and openWorldHint: false, so the safety profile is established. The description adds no extra behavioral context (e.g., what format the summary returns, whether the call must be completed, or any processing delays), but it does not contradict the annotations either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the core purpose. It is concise without being under-specified, containing 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?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the essential information. It clearly identifies the operation and resource, though it could briefly mention return value characteristics to be fully complete in the absence 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?
The schema provides full coverage for the single parameter (call_id) with a clear description ('The call ID'). The tool description adds no additional parameter semantics beyond what the schema already offers, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the AI-generated summary of a call. The qualifier 'AI-generated' distinguishes it from sibling tools like aircall_get_custom_summary or aircall_get_transcript, and the verb+resource structure is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as aircall_get_custom_summary or aircall_get_sentiments. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds minor context about tags being used for categorizing calls, but does not describe pagination behavior or return details. With annotations covering safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three optional parameters and no output schema. The description conveys the core purpose, and the schema covers the pagination parameters. It is sufficiently complete for an agent to use correctly, though it could mention pagination explicitly.
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?
All three parameters (page, order, per_page) have explicit descriptions in the schema, achieving 100% coverage. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List'), the resource ('all tags'), and the context ('for categorizing calls'). It distinguishes from aircall_get_tag by explicitly covering all tags rather than a single one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like aircall_get_tag. The description simply states what it does without mentioning when to choose it or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description is consistent. However, the description adds no extra context such as whether the removal is permanent, whether the phone number itself is deleted from the account, or if special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and object. Every word is meaningful with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal operation with good schema coverage and annotations, the description is largely sufficient. It could be improved by mentioning post-conditions (e.g., what happens to the number's assignment) or error scenarios, but the current level 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 input schema provides complete descriptions for both parameters (user_id and phone_number_id), achieving 100% schema coverage. The description adds no additional semantic meaning beyond what the schema already states.
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 'Remove' and the resource 'a phone number from a user's power dialer campaign.' It distinguishes itself from sibling tools like aircall_add_campaign_numbers and aircall_get_campaign_numbers by focusing on removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of alternatives. It does not mention the opposite operation (add campaign numbers) or any prerequisites such as the user_id needing an existing power dialer campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating a state-changing but non-destructive operation. The description adds the qualifier 'active call,' which implies a precondition, but otherwise discloses no additional behavioral traits such as permissions, side effects, or error conditions.
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 entire description is a single, focused sentence that communicates the action, resource, and target without any filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage and safety annotations, the description is reasonably complete. It clarifies the 'active call' precondition and the transfer target, though it doesn't mention response behavior or failure modes, which is acceptable given the lack 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 100%—both parameters already have descriptions ('The call ID' and 'User ID to transfer to'). The description adds minimal semantic value beyond restating the target user, so it meets the baseline but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Transfer') on a specific resource ('active call') with a destination ('another user'), distinguishing it from sibling call-management tools like get_call or archive_call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It is a bare statement of functionality, so the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating a write operation that is not destructive. The description adds the optional callback URL behavior but does not disclose side effects such as whether an existing configuration is overwritten, whether the number must exist, or any authentication requirements. It provides some value beyond annotations but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary purpose ('Create the messaging configuration'), and every part is relevant. There is no redundant information or filler, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only two parameters and no output schema. The description covers the core purpose and optional parameter, but it does not mention return values, whether the operation is idempotent, or prerequisites like the number existing. Given the lack of an output schema, some additional context would improve completeness, but the current level is acceptable for a basic create 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 100%, so the baseline is 3. The description adds context by explaining that callback_url is for incoming message events, but it does not elaborate on how number_id and callback_url interact or any constraints beyond what the schema already states. The added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create), the target resource (messaging configuration for an Aircall number), and an optional behavior (setting a callback URL). This distinguishes it from sibling tools like aircall_get_config and aircall_delete_config by explicitly using 'create' and 'messaging configuration'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting up a number's messaging configuration, and the optional callback URL provides context. However, it offers no explicit guidance about when to use this tool versus alternatives (e.g., aircall_create_webhook) or any exclusions/prerequisites, so it only meets the 'implied usage' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, covering the read-only nature. The description adds that it returns 'detailed information' but does not disclose what fields are included, behavior when contact is not found, or any response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It is front-loaded with the purpose and is appropriately sized for a simple get-by-ID tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the lack of an output schema means the description should set expectations about the return value. Saying 'detailed information' is vague and does not specify the contact attributes or error conditions, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (contact_id) with full description coverage. The description adds no additional semantic meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action 'Get' and clearly identifies the resource as 'a specific contact', which distinguishes it from list/search siblings. It conveys exactly what the tool does: retrieve one contact's details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a single contact's details) but does not explicitly state how it differs from aircall_list_contacts or aircall_search_contacts, nor does it mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, so the description correctly aligns with them. The description adds context about the return payload (members and assigned numbers) but does not disclose pagination behavior or other operational details beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the main action and resource. No wasted words; it efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is clear, it lacks coverage of pagination behavior despite having page and per_page parameters, and there is no output schema. It does not mention that 'all teams' may require pagination or how results are ordered, leaving some ambiguity for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 3 parameters (page, order, per_page) with 100% coverage, so the description adds no additional parameter meaning. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('teams') and clearly states the scope ('all teams') and content ('with their members and assigned numbers'). This effectively distinguishes it from the sibling tool aircall_get_team, which retrieves a single team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'all teams', which suggests listing all teams rather than a specific one, but it does not explicitly state when to use this tool versus alternatives like aircall_get_team, nor does it mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds modest value: 'all configured webhooks' signals full enumeration (no filtering), and the webhook explanation provides domain context. However, it does not disclose return format, pagination behavior, or any permission requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero fluff, and the core purpose is front-loaded in the first sentence. The second sentence earns its place by supplying domain context about webhooks (real-time notifications for calls, contacts, user status), which aids tool selection. It is slightly less tool-behavior-focused than an ideal 5, but it is appropriately sized and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two well-documented optional pagination params and strong annotations, the description is largely sufficient. The absence of an output schema means the description could have gone further to state what the returned list contains (e.g., webhook URLs/events), which is a minor gap. Overall, the combination of clear purpose, full schema coverage, and safe-operation annotations makes this mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both page and per_page are fully documented with defaults and a max constraint. The description adds no parameter information, but per the baseline rule, a score of 3 is appropriate since the schema already carries the full semantic weight for both 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 a specific verb+resource+scope: 'List all configured webhooks.' This clearly distinguishes the tool from its sibling aircall_get_webhook (singular fetch) and the create/update/delete webhook tools. The second sentence adds functional context about what webhooks do, further disambiguating it from unrelated list tools in the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the verb 'List' — an agent can infer to use this when enumerating webhook configurations. However, there is no explicit when-not guidance or named alternatives (e.g., 'use aircall_get_webhook to retrieve a single webhook'), despite a relevant singular sibling existing. The webhook context sentence provides domain background but not usage selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already establishes this as a safe read operation. The description adds 'Returns matching contacts,' which is somewhat tautological with 'Search' but does clarify the output. It does not disclose matching behavior (exact vs partial), whether parameters can be combined, or pagination. Given the annotation coverage, the description provides minimal additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: 'Search contacts by phone number or email. Returns matching contacts.' Every word earns its place. It is front-loaded with the action and resource, and there is zero redundancy.
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 search tool, the description covers the core functionality, and annotations handle the read-only safety. However, it leaves ambiguity about how the two optional parameters interact (e.g., AND vs OR), what happens if neither is provided, and whether exact or partial matching is used. These are notable gaps for a search tool, especially since the schema shows both parameters as optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'email' and 'phone_number' already described as search criteria. The description's phrase 'by phone number or email' adds no semantics beyond the schema. Baseline of 3 is appropriate since the schema carries the parameter meaning fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search contacts by phone number or email.' This uses a specific verb ('Search') and resource ('contacts'), and explicitly identifies the search criteria. It distinguishes itself from sibling tools like aircall_list_contacts (list all) and aircall_get_contact (get by ID) by focusing on phone/email 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 implies the use case: find a contact when you have a phone number or email. However, it does not provide explicit guidance on when to use this tool versus alternatives such as aircall_get_contact or aircall_list_contacts, nor does it mention any exclusions or prerequisites. The guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds context that the operation targets a power dialer campaign and is user-specific, but does not disclose behaviors such as duplicate handling, idempotency, or whether it replaces existing numbers. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, with no extraneous information. It is appropriately sized for a simple operation.
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, two fully documented parameters, and no output schema, the description plus annotations are largely sufficient. It could mention edge cases like duplicate numbers or behavior when the campaign does not exist, but these are not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes both parameters (user_id and phone_numbers in E.164 format) with 100% coverage. The description does not add additional semantic meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Add' with the resource 'phone numbers to a user's power dialer campaign,' clearly stating the action and target. It distinguishes itself from sibling tools like aircall_remove_campaign_number and aircall_get_campaign_numbers by focusing on adding numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when adding phone numbers to a user's power dialer campaign) but provides no explicit guidance on alternatives, prerequisites, or when not to use it. It lacks comparison to sibling tools like aircall_remove_campaign_number or aircall_get_campaign_numbers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive nature (destructiveHint=false). The description adds the behavioral trait that comments are visible in the Aircall dashboard, but does not disclose additional side effects, permissions, or failure modes. This is modest added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary action is front-loaded, and the dashboard visibility note adds useful context without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no output schema, the description covers the core purpose and a key behavioral outcome. It does not cover potential edge cases (e.g., invalid call_id) or prerequisite conditions, but given the tool's simplicity, the information is adequate for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are documented in the schema with simple descriptions (call_id: 'The call ID', content: 'Comment content'). The tool description adds no additional parameter-level detail, but schema coverage is 100%, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a comment to a call') with a specific verb and resource. The additional clause about visibility in the Aircall dashboard helps distinguish this tool from sibling tools like aircall_add_tags, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a comment needs to be added to a call, but does not explicitly state when to use this tool versus alternatives or mention any exclusions. The visibility note provides some context but no comparative guidance against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal this is not read-only and not destructive. The description adds the useful behavioral fact that users can be in multiple teams, but does not disclose potential failure modes (e.g., duplicate membership) or permission requirements. It adds some context but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the operation directly; the second adds a relevant nuance. 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 simplicity, two params fully documented in schema, and annotations covering read/write/destructive, the description is mostly complete. It clarifies the multiple-team capability, which helps the agent understand repeated use. Missing only minor details like error handling, but not necessary for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (team_id and user_id are both described as numbers with clear labels). The description does not add further param details, so the schema carries the full burden. Per guidelines, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a user to a team') and the resources involved, distinguishing it from sibling tools like aircall_remove_user_from_team. The added detail that 'Users can belong to multiple teams' clarifies a key semantic, removing ambiguity about repeated additions.
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 context is clear: this tool is for adding a user to a team, and the multiple-team note implies users can be added to several teams without conflict. However, there is no explicit guidance on when to use this vs. alternatives (e.g., when a user already belongs to a team, or prerequisites like valid IDs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds no extra behavioral context such as required fields, permissions, or return values. It does not contradict annotations, but provides minimal additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's function. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with no output schema, the description adequately conveys the purpose. The optionality of phone numbers and emails is highlighted, though it does not mention that all other fields are also optional or describe the return value. Still, it is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented. The description only highlights that phone numbers and emails are optional, which the schema already implies by not including them in 'required'. No additional semantic value is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new contact'), and explicitly mentions optional phone numbers and emails, which distinguishes it from sibling contact tools like list, get, update, and delete.
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 purpose of the tool is implied (use when you need to create a contact), but there is no explicit guidance on when to use this vs. alternatives like aircall_update_contact or aircall_delete_contact. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false) correctly indicate a write operation, and the description is consistent. The description adds the context that tags are for categorizing calls, but it does not disclose other behavioral traits such as required permissions, whether the created tag gets an ID in the response, or if it is immediately usable. With annotations covering the basic safety profile, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word serves a purpose, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple CRUD operation with full schema descriptions and annotations, the description sufficiently conveys the tool's purpose. No output schema exists, so return-value details are not required. It is complete enough for an agent to select and invoke the tool correctly, though it could mention any prerequisites or side effects if applicable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all parameters (100% coverage), including name, color, and description. The tool description itself does not add parameter-specific meaning beyond the schema, so the baseline of 3 applies. No extra syntax or semantic detail is offered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create') and the resource ('a new tag') with a specific purpose ('for categorizing calls'). This distinguishes it from sibling tools like update_tag, delete_tag, and list_tags, making the tool's role immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new tag is needed for call categorization, but it does not explicitly mention alternatives or when not to use this tool. Sibling tools (e.g., update_tag, delete_tag) exist, yet no comparison or exclusionary guidance is provided, leaving usage context mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the create operation and provides context that teams group users, which aligns with annotations declaring readOnlyHint=false and destructiveHint=false. However, it does not add deeper behavioral context such as permissions, return value, or post-creation effects beyond what the annotations already imply. The additional context is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action 'Create a new team', and contains no redundant or fluff text. Every word earns its place, making it appropriately concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter create tool, the description is adequate: it specifies the action, the resource, and the purpose. It could mention the return value or required permissions, but the annotations and schema already address safety and parameters, so the description is sufficiently complete for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the only parameter 'name' with 'Team name', so schema coverage is 100%. The description adds no extra semantics about the parameter, such as uniqueness, format, or constraints, leaving the schema to carry the full meaning, which meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new team' with a specific verb and resource, making it distinct from sibling tools like aircall_delete_team or aircall_get_team. It also provides context that teams group users for call routing and organization, which reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by the action itself but provides no explicit guidance on when to use this tool versus alternatives like aircall_delete_team or aircall_list_teams. No exclusions or prerequisites are mentioned, so it's a baseline 'implied usage' score.
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 is consistent with annotations (destructiveHint=true), but adds no behavioral context beyond what annotations already provide. It does not disclose side effects like irreversibility or cascade effects on campaign numbers, but with destructiveHint already present, the bar is lower.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that conveys the action and target without unnecessary words. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the destructiveHint annotation, the description is largely complete. It could mention that deletion is permanent or that it only affects the specified user's campaign, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters and includes a description for user_id. The tool description adds no additional parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('a user's power dialer campaign'), clearly distinguishing this from sibling delete tools like aircall_delete_config or aircall_delete_contact. It precisely identifies the target of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when deleting a user's power dialer campaign) but does not explicitly state exclusions or alternative tools. For instance, it doesn't mention that aircall_get_campaign should be used to verify existence first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, and the description aligns with that by saying 'Delete'. It adds the scope 'messaging configuration for an Aircall number' but no extra behavioral context like irreversibility or side effects. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that says exactly what is needed with no filler. It is front-loaded with the action and resource, making it easy to parse.
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 delete tool with one parameter, no output schema, and helpful annotations. The description adequately covers the tool's function and target. It does not explain the response or post-conditions, but for a simple delete with annotations, this 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?
The input schema has 100% coverage with a clear description for number_id ('The Aircall number ID'). The tool description's phrase 'for an Aircall number' mirrors the schema but adds no additional meaning or format details. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Delete') targeting a specific resource ('messaging configuration') scoped to an Aircall number. It distinguishes from sibling tools like aircall_delete_campaign or aircall_create_config, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to delete a messaging config) but lacks explicit guidance on when to prefer this over alternatives or any exclusions. No alternative tools are mentioned, and no when-not-to-use conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, but the description adds meaningful context by stating 'Permanently delete' and 'This cannot be undone.' This discloses irreversibility and specifically identifies what gets destroyed (the voicemail of a call), going beyond the generic destructive flag.
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 short sentences, front-loaded with the main action ('Permanently delete') and an immediate consequence. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter destructive tool, the description covers purpose, permanence, and the affected resource. It lacks any mention of error conditions or preconditions (e.g., voicemail existence), but given the simplicity and strong annotations, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter call_id described as 'The call ID.' The description does not add extra parameter detail, but none is needed since the schema fully documents it. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Permanently delete the voicemail of a call.' The verb 'delete' and resource 'voicemail' are specific, and it distinguishes from similar tools like aircall_delete_recording and aircall_archive_call. The emphasis on 'permanently' and 'cannot be undone' reinforces the action's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description does not mention when to use this tool versus alternatives (e.g., when to delete a voicemail vs. a recording), nor does it state any preconditions or exclusions. The context of usage is entirely implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral consequence that the URL will no longer receive event notifications, which goes beyond the destructiveHint annotation. However, it does not disclose other aspects such as permanence or any required permissions. Given the annotation already marks destructive, 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 extremely concise: two short sentences, with the main action in the first word and the consequence in the second sentence. No filler or redundant information, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter), the annotations provide destructive hint, and the description clarifies the purpose and effect. This is sufficient for an AI agent to understand the tool's behavior. While it doesn't reference sibling webhook tools or mention irreversible deletion, the low complexity and existing annotations make this adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter, webhook_id, whose description ('The webhook ID to delete') already provides full clarity. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a webhook.' It identifies the specific resource (webhook) and the action (delete), and adds a specific consequence ('The URL will no longer receive event notifications'), which distinguishes it from sibling tools like create/update/get/list webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for deleting a webhook, and the consequence is stated. However, it does not explicitly provide guidance on when to use this tool versus alternatives (e.g., 'Use when you want to stop notifications; use update to modify instead'). The context is clear but not explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only basic hints (not read-only, not destructive). The description adds the key behavioral fact that the user must manually initiate the call, which is useful but limited. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and key nuance. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter action with no output schema, the description adequately explains the tool's purpose and the manual-initiation nuance. It could mention prerequisites like the app needing to be installed, but overall it is sufficient for a task-level understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters already described. The description adds no additional parameter meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens the Aircall phone app with a pre-dialed number and explicitly notes the user initiates manually. This distinguishes it from sibling tools like aircall_start_call by emphasizing manual initiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (pre-dialing for manual user initiation) but does not explicitly name alternatives or when not to use this tool. Given siblings like aircall_start_call and aircall_transfer_call, explicit guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds behavioral value by enumerating the returned data elements (comments, tags, participants, recording URLs), which goes beyond the annotation and provides useful context about the tool's output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the core action and resource, and contains no redundant phrases. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers the essential return categories. It does not mention caveats like recording URL availability or authentication, but these are not critical for basic usage and the annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter call_id described as 'The call ID'. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'specific call', and specifies the scope ('detailed information') along with key data categories (comments, tags, participants, recording URLs). This distinguishes it from list/search/transcript tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like aircall_list_calls or aircall_search_calls. The phrase 'specific call' implies a known call ID, but the description does not state this condition or contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'Get' is consistent. The description adds the campaign scope context but does not disclose pagination behavior or return format details, which could matter given page/per_page params.
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?
A single, front-loaded sentence with no filler. It states exactly what the tool retrieves in a compact form.
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 low-complexity read-only tool with a clear description and fully documented schema, this is nearly complete. It lacks explicit mention of pagination behavior, but the schema's page/per_page descriptions and the absence of an output schema make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (user_id, page, per_page) are already documented. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the exact resource: 'phone numbers in a user's power dialer campaign.' It clearly distinguishes from siblings like aircall_get_campaign (campaign details) and aircall_get_user_numbers (all user numbers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: call this when you need a user's power dialer campaign phone numbers. No explicit alternatives or exclusions are mentioned, but the specificity of the resource makes it clear enough for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as readOnlyHint: true, and the description's 'Get' is consistent. The description adds no extra behavioral details (e.g., what configuration fields are returned or if any authentication is needed), but for a straightforward read operation the minimal disclosure is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the action and resource, and every word is functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, read-only hint, no output schema), the description is sufficiently complete. It states exactly what the tool does and for which resource, leaving no critical gaps for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (number_id) with a clear description. The tool description repeats the resource context but adds no new parameter-level semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource ('messaging configuration for an Aircall number'), making its purpose immediately obvious. It distinguishes itself from sibling tools like 'aircall_get_number' (which retrieves number details) and 'aircall_create_config'/'aircall_delete_config' (which modify config).
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 implicitly indicates this is for retrieving messaging configuration, but provides no explicit guidance on when to use it versus alternatives such as 'get_number' or 'create_config'. There are no stated exclusions or alternative recommendations, leaving the agent to infer context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds context about the content (scorecards, feedback, scores) but does not disclose other behavioral details such as failure modes or permission requirements. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. There is no wasted wording, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with annotations and full schema coverage, this description is adequately complete. It explains what is returned (evaluations, scorecards, feedback, scores) and implies the input. It doesn't cover edge cases or response format, but that is not necessary given the tool's simplicity and existing structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes call_id with a clear description, so it carries the parameter meaning. The description only reiterates 'for a call' without adding any additional format or usage detail, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets call quality evaluations, listing examples (scorecards, feedback, scores) and specifying scope 'for a call.' This distinguishes it from sibling tools like aircall_get_sentiments or aircall_get_topics, which target different call data.
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?
No explicit when-to-use or alternative guidance is provided, but the description's clear purpose implies usage for retrieving quality evaluations. The sibling tool list is not referenced, so the agent must infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe read operation. The description adds some value by mentioning 'adherence score and per-topic results,' which hints at the return contents, but it does not disclose any further behavioral traits such as required permissions or response format. This is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It contains no filler, repetition, or unnecessary detail. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one parameter, no output schema, and read-only annotations—the description provides enough context to understand what it does. It mentions the key deliverables (adherence score and per-topic results) but does not specify the exact structure of the response or potential edge cases. For a straightforward getter, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter call_id having a description ('The call ID'). The description itself adds nothing beyond what the schema already provides, so the baseline of 3 for full schema coverage applies. No additional meaning is given to the 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 clearly states the tool's function: 'Get the playbook result for a call, including adherence score and per-topic results.' The verb 'Get' is specific, and the resource 'playbook result' distinguishes it from related sibling tools like get_sentiments or get_summary. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the clear resource name—if an agent needs playbook results for a call, this is the tool. However, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. The description does not differentiate from potentially similar tools beyond naming the resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns by using 'Get'. It adds a useful nuance that the score is AI-predicted rather than actual, but does not disclose other behavioral details such as error conditions or response format, which is acceptable given the tool's simplicity.
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, tightly focused sentence with no extraneous information. It front-loads the core action and target, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description adequately conveys what the tool does and what it returns (the predicted CSAT score). It does not describe return formatting, but the expected return is clear from the description and semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with call_id fully described as 'The call ID'. The description adds no additional semantic detail about the parameter, but the schema already provides sufficient meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'AI-predicted customer satisfaction (CSAT) score for a call'. This is concise and unambiguous, and distinguishes it from sibling tools like aircall_get_sentiments or aircall_get_call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when an AI-predicted CSAT score for a specific call is needed. However, it does not explicitly contrast it with alternatives or provide context on when not to use it, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring readOnlyHint=true, the description aligns by indicating a read operation. It adds useful context about the response including members and numbers, but does not disclose other behavioral traits like pagination or potential errors. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence front-loaded with the action and resource, then immediately specifying what is included. No filler or redundant 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?
For a simple getter with one parameter, readOnly annotation, and no output schema, the description sufficiently explains purpose and result content. It is complete enough without needing to explain return format or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (team_id described as 'The team ID'). The description does not add deeper parameter semantics, so the schema carries the meaning; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Get detailed information about a specific team') and adds what is included ('all members and numbers'), clearly distinguishing from sibling tools like aircall_list_teams by emphasizing 'specific team'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need details of a specific team, implying you have a team_id), but does not explicitly mention alternatives, such as aircall_list_teams for listing all teams, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read. The description adds context about the return contents (numbers and availability), which is useful since there is no output schema. However, it doesn't discuss error handling, permissions, or other behavioral traits beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose and key included data. Every word contributes, with no filler or redundancy. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description is sufficiently complete. It covers the main return elements (numbers and availability) despite lacking an output schema, and the readOnlyHint annotation covers the safety profile. Slight vagueness in 'detailed information' prevents a perfect score, but overall it 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?
Schema coverage is 100% for the single user_id parameter with a clear description. The tool description adds little semantic meaning about the parameter itself, just reinforcing that it targets a 'specific user.' No additional parameter details are provided, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (get detailed information) on a specific resource (a particular user), and distinguishes itself from siblings like aircall_list_users (which lists users) and aircall_get_user_numbers (which only gets numbers) by specifying that it returns detailed info including both numbers and availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific user_id and need comprehensive user details, but it does not explicitly mention alternatives or exclusions. There is no 'when not to use' guidance, so it stops at implied usage without naming sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and openWorldHint annotations already establish this is a safe read operation. The description adds the detail that the response includes subscribed events, which provides some return-value context, but it doesn't disclose additional behavioral traits like required permissions or response structure. With annotations covering the safety profile, this adds minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 11 words, front-loaded with the action and resource. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description is adequate: it states the purpose and the notable return detail (subscribed events). However, it could be slightly more explicit about what other fields are included, but given the simplicity, it's complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with 'The webhook ID' for webhook_id. The tool description doesn't add any additional parameter semantics beyond reinforcing that a specific webhook is targeted, which is already in the schema. No need for more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'get' with the resource 'webhook' and clarifies it returns detailed information including subscribed events. This distinguishes it from list/create/update/delete webhook siblings, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a specific webhook by ID, contrasting with listing all webhooks. However, it doesn't explicitly name alternatives like aircall_list_webhooks or state exclusions, so guidance is only implied, not 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?
Annotations already declare readOnlyHint=true and openWorldHint=false, establishing a safe read operation. The description adds useful behavioral context by mentioning pagination and the specific return fields (phone numbers, emails), going beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and immediately followed by output details. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated list tool with full schema documentation and read-only annotations, the description is sufficiently complete. It covers the purpose, return content, and pagination, though it could optionally mention default orders/filters, but these are already in the 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?
The input schema has 100% coverage with clear descriptions for all five parameters. The description mentions pagination, which relates to page/per_page, but adds no extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all contacts with pagination and returns contact details including phone numbers and emails. The verb 'List' and resource 'contacts' are specific, and scope 'all' is implied. It lacks explicit differentiation from sibling tools like aircall_search_contacts, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the word 'all' — this tool is for retrieving complete contact lists, while filtered searches would use aircall_search_contacts. However, no explicit guidance or alternatives are mentioned, so clarity is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only safety profile is covered. The description adds context about the return content (configuration and assigned users) but does not disclose pagination behavior or other operational details beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and object, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with full parameter schema and readOnlyHint annotation, the description is largely sufficient. It specifies the scope ('all phone numbers') and the included data ('configuration and assigned users'), which partially compensates for the lack of an output schema. It doesn't mention pagination explicitly, but the schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (page, order, per_page) is already documented. The description adds no additional parameter semantics or syntax details beyond the schema, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('all phone numbers in the account'), and adds what is included ('configuration and assigned users'). This distinguishes it from siblings like aircall_get_number (single number) and aircall_update_number (mutation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a listing use case but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool mentions are given, so the agent must infer from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds no further behavioral context (e.g., whether it replaces the existing email entirely, effect on linked records, or reversibility). It does not contradict the annotations, but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that immediately states the action and target. No wasted words, front-loaded with the verb. It is efficient and fully digestible, fitting the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, 100% parameter coverage, and existing annotations, the description is mostly complete. However, there is no output schema, and the description does not mention what the operation returns (e.g., the updated email object, success status) or any side effects beyond 'update', which is a minor gap for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters (label, value, email_id, contact_id), each with clear descriptions. The description itself adds no parameter-specific meaning, so it does not compensate beyond the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an email address on a contact' uses a specific verb ('Update') and names the exact resource ('an email address on a contact'). It clearly distinguishes from sibling tools like aircall_add_email and aircall_delete_email by implying an existing email is modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or alternatives. Usage is implied by the verb 'Update' in contrast to sibling tools like add/delete, but there is no statement about prerequisites, when to prefer this over aircall_update_contact, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds minor context by listing the specific fields that can be changed, but does not explain partial-update behavior or consequences beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the verb and resource. No superfluous 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?
For a straightforward update operation with a documented schema and safety annotations, the description is sufficient. However, it could note whether omitted fields are preserved or whether events replaces the entire list, though the required-field schema already implies partial updates.
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?
All four parameters have schema descriptions (100% coverage), including the enum values for events. The tool description merely restates the field names (URL, events, active status) without adding syntax, constraints, or behaviors not already in the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' and identifies the resource (a webhook) plus the specific mutable fields (URL, events, active status), making it clear and distinct from sibling tools that create/delete/get webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus creating, deleting, or listing webhooks. The use case is implied by the verb 'update', but there are no exclusions or alternative recommendations, so it's minimally adequate.
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 annotation readOnlyHint=true already indicates this is a safe read operation, and the description aligns with that. The description adds the temporal qualifier 'currently', implying real-time status, but doesn't disclose return format or further behavioral details. Since annotations cover the safety profile, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that gets straight to the point. No filler, unnecessary jargon, or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and the annotations provide safety context. However, with no output schema, the description should clarify what the agent receives (e.g., a boolean or availability status). It says 'check' but not 'returns true/false', which is a minor gap. Still, for a simple read-only check, 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 schema provides 100% coverage for the only parameter (user_id) with a clear description 'The user ID'. The tool description adds no additional parameter information, so the baseline of 3 applies. There is no gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'check' and names a precise resource: 'if a specific user is currently available to take calls.' It clearly distinguishes from a generic 'get_user' tool by focusing on current availability, which is a unique purpose. The scope is explicit and narrow.
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 a clear use case: checking a user's availability before routing a call. It doesn't explicitly name alternatives or exclusions, but the context is self-evident. Given the sibling tools include 'aircall_get_user' and 'aircall_list_availabilities', some comparison would strengthen this, but the intended usage is still unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, covering the mutation safety profile. The description adds that URLs are required for audio files, but doesn't clarify partial vs. full update behavior or side effects on omitted fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the action, resource, and key instruction. No wasted words.
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?
With 11 parameters and no output schema, the description is somewhat sparse. It doesn't explain whether updates are incremental or full replacements, or how to handle optional parameters. Annotations cover destructiveness, but the update semantics remain ambiguous for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every parameter described as a URL type. The description reinforces this by stating 'Provide URLs to audio files' and listing example messages, but adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates audio messages and music for a phone number, using a specific verb and resource. It lists examples (welcome, waiting, voicemail) and distinguishes this tool from siblings like aircall_update_number or aircall_delete_voicemail.
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: when you need to update audio messages/music for a phone number, you provide URLs. It doesn't explicitly mention alternatives or exclusions, but no direct sibling tool overlaps, so the usage scenario is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds no further behavioral context beyond that, such as prerequisites (e.g., contact must exist) or potential failure modes. This is acceptable but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential action. It is concise, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description adequately covers the action. It does not detail return values or error scenarios, but such details are not critical for this simple add operation given the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for label, value, and contact_id. The description itself adds no extra semantic information beyond the schema, so it meets the baseline but does not elevate 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 uses a specific verb ('Add') and a clear resource ('a phone number to an existing contact'), distinguishing it from sibling tools like update_phone and delete_phone. It also clarifies that the target is an existing contact, not a new one, which differentiates it from create_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you want to associate a new phone number with an existing contact. It does not explicitly state exclusions or alternatives, but the context is sufficient for an agent to decide among related tools such as update_phone or add_email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive mutation (readOnlyHint=false, destructiveHint=false). The description adds value by specifying that archiving hides the call rather than deleting it, which is a meaningful behavioral trait not fully captured by the boolean annotations. It also implicitly suggests reversibility via the existence of unarchive_call.
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 action and a concise consequence. There is zero wasted text; every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter action tool with annotations and a complete schema, the description covers the essential context: what happens and the effect. It does not mention return values or error conditions, but these are less critical given the tool's simplicity and the presence of sibling tools for related operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the sole parameter call_id is documented as 'The call ID to archive.' The description adds no further context beyond the schema, so the baseline score of 3 applies without bonus or penalty.
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 ('Archive') with a clear resource ('a call'), and immediately clarifies the effect by stating archived calls are hidden from the main call list. This distinguishes the tool from siblings like unarchive_call and delete_recording by defining its exact behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the effect ('hidden from the main call list') — an agent can infer this is for removing visibility without deletion. However, there is no explicit guidance on when to choose this over alternatives such as unarchive_call or delete_recording, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds a valuable behavioral detail: an invitation email will be sent, which is a side effect not captured by annotations. However, it does not disclose permission requirements or failure 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?
Two short sentences: the first states the action, the second discloses the side effect. 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?
The description is sufficient for an agent to understand the tool's purpose and a key side effect. With a rich schema and annotations providing the safety profile, the absence of return-value documentation is acceptable, though it doesn't explain what happens on error or what the API returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the parameters (email, role_id, is_admin, first_name, last_name) with simple, self-explanatory descriptions. The tool description adds no additional parameter-level semantics, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and identifies the resource 'a new user in Aircall', clearly differentiating from sibling tools that create other entities (campaigns, contacts, teams). The additional detail about the invitation email reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new user needs to be added to Aircall, but provides no explicit guidance on when to use this tool versus alternatives like aircall_update_user or aircall_add_user_to_team. No exclusions or alternative references are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the destructiveHint=true annotation and adds specificity about what is destroyed (the email address) and from what (the contact). This clarifies the scope beyond the generic annotation, though it does not include side effects or permission requirements.
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 with no redundant words. It is front-loaded and directly states the action and target, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation with clear annotations, the description is nearly complete. It identifies the entity and the parent context. It does not specify return values, but that is acceptable given the simplicity and lack 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 100%, with each parameter already fully described ('The email ID to delete', 'The contact ID'). The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an email address from a contact' clearly specifies the action ('delete') and the resource ('email address' on a 'contact'). This distinguishes it from sibling tools like aircall_delete_phone or aircall_delete_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when an email needs to be removed from a contact) but provides no explicit guidance, exclusions, or alternatives. It does not mention other similar tools like aircall_add_email or aircall_update_email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds meaningful context: 'permanently' and 'cannot be undone', reinforcing the irreversible nature beyond what the annotation flags provide. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The core action and the crucial warning are front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter destructive tool with strong annotations, the description covers the essential purpose and irreversibility. It does not mention error states or post-deletion behavior, but the low complexity and schema coverage make this 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?
The schema covers 100% of the parameter descriptions, with call_id already described as 'The call ID'. The description does not add extra meaning about the parameter, such as format or source, so it meets the baseline but provides no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Permanently delete the recording of a call.' This distinguishes it from related tools like aircall_delete_voicemail or aircall_pause_recording. The verb 'delete' and resource 'recording' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the nature of the operation: use when a recording should be permanently removed. The warning 'This cannot be undone' advises caution, but there is no explicit guidance on when to prefer this over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds specific context beyond that: 'Existing calls with this tag will lose it.' This directly discloses the side effect on other resources, which is valuable behavioral transparency. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and followed by the key side effect. There is no redundant information or filler. It earns its place with both sentences contributing meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with annotations and no output schema, the description is appropriately complete: it states the action and the main consequence. It could mention that the tag must exist or that deletion is permanent, but the destructive hint and the side effect already cover the essential context. The description is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the tag_id parameter described as 'The tag ID to delete'. The description adds no further parameter details, but since the schema fully covers the parameter meaning, the baseline of 3 is appropriate. No additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and resource 'tag', making the action clear. It also adds the important consequence that existing calls will lose the tag, which distinguishes it from other tag-related tools like list/get/create/update. This is a clear, unambiguous statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you want to delete a tag, use this tool. However, it does not explicitly state when to use it versus alternatives or provide any exclusions. There is no mention of prerequisites or relation to other tag operations, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds a useful constraint (one active campaign per user) but does not disclose other behaviors such as return format or behavior when no campaign exists. This is consistent with the baseline for annotated read operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the main purpose and immediately provide a key constraint. There is no wasted language, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter, readOnlyHint annotation, and no output schema, the description is adequate. It explains what is returned (the active campaign) and the uniqueness rule. It could optionally mention the response when no campaign exists, but that is not critical for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for user_id, including a clear description that it targets the user whose dialer campaign to retrieve. The tool description adds no extra parameter information, so it relies on the schema, which is fully sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('a user's active power dialer campaign'). It also adds the unique constraint that each user has at most one active campaign, which distinguishes it from other campaign-related operations like create or delete.
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 by noting that each user has at most one active campaign, making it evident when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, so it lacks a full exclusion clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description's safety is covered. The description adds that the response includes users and message configuration, but it does not disclose return format or error behavior. This is similar to the 'get_calls' calibration example, where the description adds some context but not rich behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the action and scope. Every word earns its place; no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter, no output schema, and read-only annotations, the description sufficiently states what information is returned (users and message configuration). It could go further by describing the response structure or potential errors, but given the low complexity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter 'number_id' is fully described as 'The phone number ID'. The description adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed information about a specific phone number, with a verb ('Get') and resource ('specific phone number'). It distinguishes itself from siblings like aircall_list_numbers (list all) and aircall_update_number (update) by focusing on retrieving details for one number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use when you need detailed info about a particular number. It does not explicitly mention when not to use it or name alternatives, but the purpose is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe read operation. The description adds the ongoing-call constraint, which is useful. It does not disclose what happens if the call is not active or if transcription is unavailable, but given the annotation coverage, a score of 3 is appropriate.
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 only two sentences, front-loaded with the primary function, and contains no wasted words. Every sentence earns its place, providing both what and when.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no output schema) and has good annotations. The description covers the core usage (real-time, ongoing call) and timing. It could benefit from mention of output format or limitations, but given the simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, call_id, is described as 'The call ID'. The description adds no extra meaning beyond what the schema already provides. Baseline 3 is warranted since the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get real-time transcription for an ongoing call.' It uses a specific verb ('Get') and resource ('real-time transcription') and distinguishes itself from sibling tools like aircall_get_transcript by specifying 'ongoing call' rather than completed calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this during active calls to see live transcription.' This tells the agent when to invoke the tool. However, it does not explicitly name alternatives or exclusions (e.g., when a call has ended, use aircall_get_transcript), 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 is consistent with the readOnlyHint=true annotation, stating a safe read operation. It adds the compliance note as extra context, but doesn't disclose return format, potential errors, or data source. Since annotations already cover safety, this is adequate but not deeply informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the action front-loaded in the first sentence and practical context in the second. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a single parameter and no output schema, the description provides the core action and a situational motivation. It doesn't describe the return payload, but such detail isn't necessary for a basic status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents number_id with the description 'The phone number ID', and the tool description adds no additional semantic detail about the parameter. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('registration status for a phone number'), making it distinct from sibling tools like aircall_get_number which would return broader number details. The verb-resource pairing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context by noting 'Important for compliance in some regions', which signals when this tool is relevant. It doesn't explicitly name alternatives or exclusions, but the compliance rationale adequately guides selection for a niche status-checking task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context by specifying the output structure (speaker-attributed utterances with timestamps). However, it doesn't disclose edge cases like missing transcripts or recording availability, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately convey the purpose and return format. Every word is meaningful, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description is largely complete: it states what it does and what it returns. The absence of an output schema makes the return-format note valuable, though it could mention prerequisites (e.g., transcription must be enabled) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, call_id, is fully documented by the schema with the description 'The call ID'. Since schema coverage is 100%, the description doesn't need to add param semantics, and it doesn't go beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the transcription of a call and specifies the return format (speaker-attributed utterances with timestamps). This distinguishes it from related tools like get_summary or get_sentiments, though it doesn't explicitly contrast with get_realtime_transcript.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to choose this over aircall_get_realtime_transcript or other alternatives. Usage is only implied by the tool's function, so it meets the 'implied usage' level but lacks clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering safety. The description adds useful behavioral context about the return content (availability status and assigned numbers), but does not disclose pagination behavior or other potential traits. With annotations present, the added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, resource, and scope. It contains no redundancy or filler, making it highly concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema, the description adequately explains what the tool does and what information is returned (availability status and assigned numbers). Pagination is implied via schema parameters, and annotations cover safety. The description is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all parameters (page, order, per_page) with descriptions and defaults. The description does not add parameter-specific details beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'users' and explicitly mentions 'all users in the Aircall account with their availability status and assigned numbers.' This clearly distinguishes it from sibling tools like aircall_get_user (single user) and other user-management actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys that this tool is for listing all users, which implies when to use it. However, it doesn't explicitly discuss alternatives or exclusions (e.g., use aircall_get_user for a single user). The context is still clear, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false, destructiveHint=false, and openWorldHint=false, which already tell the agent this is a write operation but not destructive. The description adds that the card appears on the agent's Phone app during an ongoing call, but does not disclose whether the call must be active, what happens if the call ends, or the exact display behavior beyond the block types. No annotation contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence that packs the core purpose, target location, timing, and a concise explanation of the content format. No filler or redundant 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?
Given there's no output schema and the sibling list is vast, the description does enough to explain the call context and content structure. It doesn't mention response/return behavior, but for a push operation like this, the absence is minor since the schema fully covers inputs and annotations cover side effects. The complexity is low (2 params).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: call_id is 'The ongoing call ID' and contents is 'Content blocks to display on the card'. The description adds format details for contents (blocks like {type: 'title'|'shortText', text: ...} or {type: 'link', link: ..., label: ...}) which is helpful, but the schema already describes each property. Since coverage is high and description adds example shapes, credit is above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Push an insight card with contextual info to the agent's Phone app during an ongoing call') and differentiates this from sibling tools by naming 'insight card', 'Phone app', and 'ongoing call'—none of the sibling tools overlap with this niche. The verb 'push' plus the resource 'insight card' identifies a distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used during live calls but doesn't explicitly state when to use it versus alternatives (e.g., when not to use, prerequisites like call_id validity or agent availability). No exclusions or alternative tool names are given, but the context of 'ongoing call' gives some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries some burden. It adds that the message appears in the Aircall Inbox and is for existing threads, but it does not disclose potential failure modes (e.g., thread not found) or side effects beyond what is obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, delivers the action and context upfront, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with fully documented parameters, the description adequately covers the purpose and usage context. It could mention that the conversation must already exist or that this is intended for agent inboxes only, but it already says 'existing agent conversation thread.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters. The tool description adds no parameter-level information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Send a message') and a specific resource ('existing agent conversation thread'), with added context that it appears in the Aircall Inbox. This clearly distinguishes it from sibling tools like aircall_send_message by emphasizing it is for replying to ongoing conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this to reply to ongoing conversations' provides clear context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it, so it slightly misses a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive, which align with the description. The description adds valuable context by disclosing that the user's phone rings first before connecting to the destination, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that immediately state the primary purpose and follow with a crucial behavior detail. No filler or redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with existing schema and annotations, the description provides adequate context for call initiation. While it could mention return values or prerequisites, the core flow is sufficiently covered.
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?
Input schema descriptions fully cover all three parameters with clear meanings, achieving 100% schema coverage. The description does not add extra parameter semantics beyond the phrase 'on behalf of a user,' which is supported by the schema's user_id description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('initiate an outbound call') and the actor ('on behalf of a user'), with a specific behavioral detail (ring first, then connect). This distinguishes it from sibling tools like aircall_dial by emphasizing the user's phone ring sequence.
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?
Provides implied usage context ('on behalf of a user') but does not explicitly state when to use this tool versus alternatives such as aircall_dial or aircall_trigger_agent_call. No exclusions or alternative tool mentions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds valuable context with 'This action cannot be undone,' reinforcing irreversibility. This goes beyond the metadata, though it does not elaborate on other behaviors like permissions or cascading effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with zero unnecessary words. It states the action and an important caveat, making it highly efficient and 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 simple one-parameter delete operation with strong annotations and a clear destructive warning, the description is complete. It covers the essential action and consequence without needing additional detail; no output schema is present, but none is expected for a delete 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 coverage is 100% and the single parameter (user_id) already has a clear description. The tool description adds no additional parameter meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a user from Aircall') with a specific verb and resource. The phrase 'from Aircall' clarifies that it removes the user account itself, distinguishing it from sibling tools like aircall_remove_user_from_team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for permanently deleting a user but provides no explicit guidance on when to use this tool versus alternatives (e.g., aircall_remove_user_from_team for team removal). There is no when-to-use or exclusion context beyond the core action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=false. The description adds the scope 'associated with the current API credentials' but does not disclose potential side effects, reversibility, or impact on ongoing operations. It does not contradict the annotations, so a mid-range score is appropriate.
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?
A single, clear sentence that conveys the purpose without any filler. The information is front-loaded, making it easy for an agent to quickly understand the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is sufficiently complete. It identifies the target resource and the action, and the scope is clarified by 'current API credentials'. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema to explain. The description is not required to detail parameters, and the baseline for a zero-parameter tool is high. It does not add parameter-specific information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Disable' and the resource 'the integration associated with the current API credentials', making its action unambiguous. It distinguishes itself from sibling tools like aircall_enable_integration and aircall_get_integration by explicitly targeting the disable operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to disable the current integration, but it lacks explicit guidance on when NOT to use it or which alternatives to prefer. There is no mention of checking integration status via aircall_get_integration or re-enabling via aircall_enable_integration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns. It adds valuable behavioral context: the requirement for 'AI Assist Pro' and the return shape ('results for each custom summary template section'). This goes beyond what annotations provide, giving the agent actionable expectations about licensing and output.
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 action, and every word contributes. It states the core purpose first, then provides key qualifiers (license requirement and return format). No unnecessary filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description provides sufficient context: it identifies the required license, clarifies what the response contains, and is consistent with annotations. There is no output schema, but the description explains the return value sufficiently. No obvious gaps for an agent to select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter ('call_id' with description 'The call ID'), so baseline is 3. The description does not add additional details about the parameter format or source, but it reinforces the connection to 'a call'. No extra semantic value beyond 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's purpose: 'Get the custom summary result for a call'. It uses a specific verb ('Get') and resource ('custom summary result'), distinguishing it from siblings like aircall_get_summary by emphasizing the 'custom' nature. The additional context about AI Assist Pro and template sections further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a custom summary is needed) but does not explicitly contrast it with alternatives such as aircall_get_summary or aircall_get_playbook_result. There is no explicit 'use this vs that' guidance, though the description's clarity about custom summary provides some direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds useful context by specifying 'all phone numbers' and 'API v2', which clarifies scope and versioning. No behavioral contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. Every word contributes meaning, with no redundant filler or repetition of the tool name.
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 a single required parameter and read-only annotation, the description fully covers the tool's purpose and scope. There is no output schema, but the description's mention of 'all phone numbers' implies the return type sufficiently for a simple getter. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description for user_id ('The user ID'). The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all phone numbers assigned to a specific user' uses a specific verb ('Get') with a clear resource ('phone numbers assigned to a specific user') and scope ('specific user'). This distinguishes it from sibling tools like aircall_list_numbers (all numbers) or aircall_get_number (a single number).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a user_id and need their assigned phone numbers, but it does not explicitly state when to use it over alternatives. It does not mention alternatives or exclusions, so it relies on the user to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating a non-read-only mutation. The description adds the prerequisite that the call must be active and recording paused, but doesn't disclose behavior when conditions aren't met or any side effects. Given the annotations, this is minimal but acceptable additional 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?
A single sentence that is direct and front-loaded with the action. Every word earns its place, with no filler or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and good annotations, the description fully conveys the purpose and condition. The sibling context and the tool's simplicity mean no additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with call_id described as 'The call ID.' The description does not add any extra semantic detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Resume' with the resource 'recording' and clearly states the scope 'on an active call after it was paused.' This distinguishes it from sibling tools like aircall_pause_recording and aircall_delete_recording, 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 states the precondition 'after it was paused' and the target 'active call,' giving clear context for when to use the tool. While it doesn't explicitly name alternatives, the sibling list includes aircall_pause_recording, making the relationship obvious. It lacks explicit exclusion scenarios but the usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (a write operation). The description adds useful behavioral context: the agent must be configured in the dashboard, and every {{variable}} needs a matching key in context. These are important prerequisites not fully captured by annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, and no filler. The first sentence states the core action; the second adds essential requirements. Very concise.
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?
With no output schema, the description should clarify the return value or post-trigger behavior, but it doesn't. It covers prerequisites and the variable-matching requirement, which is helpful, but omits what the caller can expect (e.g., async status, idempotency implications). This is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the context placeholder rule already in the schema ('Every {{variable}}... must have a matching key in context') but does not add substantial new meaning beyond that, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Trigger an outbound call handled by an Aircall AI Voice Agent.' This is a specific verb plus resource and distinguishes this tool from sibling call tools like aircall_dial or aircall_start_call by highlighting the AI Voice Agent aspect.
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 for AI-agent-driven outbound calls and provides necessary preconditions (agent configured with connected number and first message). It does not explicitly mention alternatives or when not to use, but the context is clear. This fits 'clear context, no 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?
Annotations indicate readOnlyHint=false and destructiveHint=false, aligning with the mutation implied by 'unarchive.' The description adds the specific behavioral outcome of restoring the call to the main list, which is useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the purpose and effect without any extraneous information. It is front-loaded with the primary verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core functionality and effect. However, it does not mention error conditions (e.g., call not found or already unarchived) or what the response contains, which would be marginally useful but not essential given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for call_id, but the parameter description in the schema incorrectly states 'The call ID to archive' instead of 'unarchive.' This is a copy-paste error and misleading for the tool's purpose. The description does not correct or add parameter meaning, so it fails to compensate for the schema's inaccuracy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Unarchive a previously archived call, restoring it to the main call list.' This uses a specific verb and resource, and distinguishes it from the sibling tool aircall_archive_call by indicating the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use when a call is archived and needs to be restored to the main list. It does not explicitly mention alternatives or when not to use, but the context is sufficient for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false). The description adds meaningful behavioral context beyond that: the campaign is created 'active' immediately, and the one-active-campaign restriction is disclosed. It stops short of explaining failure modes if the constraint is violated, but the added details are valuable.
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-loads the primary purpose, and contains no redundant or filler content. Every sentence carries meaningful 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?
Given the tool's simplicity (2 params, no output schema), the description covers key aspects: what it does, the active nature, and the uniqueness constraint. The main gap is not explaining what happens if a user already has an active campaign (rejection vs. replacement), but the constraint is at least stated for the agent to reason about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for both parameters (user_id and phone_numbers with E.164 format). The description's mention of 'list of phone numbers to dial' adds minimal additional semantic value over the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Create an active power dialer campaign for a user with a list of phone numbers to dial.' It clearly distinguishes from sibling campaign tools like aircall_get_campaign, aircall_delete_campaign, and aircall_add_campaign_numbers by specifying the create action and the 'for a user' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need to start a new active power dialer campaign. The constraint 'A user can have only one active campaign' gives important usage context, implying the need to check for an existing campaign. However, it does not explicitly name alternatives or exclusions (e.g., adding numbers to an existing campaign via aircall_add_campaign_numbers).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description need not repeat that. It adds a non-obvious behavioral detail—users in the team are not deleted—which goes beyond the annotation and helps the agent understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that front-load the verb and resource. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with clear annotations, the description covers the essentials: what is deleted and what is preserved. It could mention potential impact on other team-associated resources, but this is not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a full description for team_id (100% coverage), and the tool description adds no additional parameter information. Baseline 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and resource (team), and adds a crucial distinction that users in the team are not deleted, which differentiates it from sibling tools like aircall_delete_user or aircall_remove_user_from_team.
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 when to use this tool by clarifying that users are preserved, providing implicit exclusion for user deletion tasks. However, it does not explicitly name alternatives or give a definitive when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given readOnlyHint=true, annotations already signal a safe read. The description adds value by disclosing the return payload (direction, status, duration, associated contacts/users) and pagination behavior, going beyond the annotation's safety indication. It does not address rate limits or auth, but with a read-only hint those are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb and resource, then adds valuable specifics about optional filters and return contents. Every word contributes, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with 100% schema parameter coverage and readOnlyHint, the description provides sufficient context for an agent to understand the tool's purpose, its optionality, and the response summary. It does not detail envelope structures like pagination metadata, but for a straightforward list tool this is not a significant 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?
Input schema coverage is 100%, with every parameter having a description (including defaults and enums). The description does not add any parameter-specific semantics beyond what the schema already provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List calls with optional filters,' which is a specific verb+resource statement. It further distinguishes this tool from single-call or search siblings by mentioning 'paginated call history' and specific return fields, making it clear this is a collection-listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that filters are optional and indicates the tool returns paginated call history, giving clear context for when to use it. However, it does not explicitly name alternatives like aircall_search_calls, nor does it provide exclusions (e.g., when to use a different tool), so it lacks full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutation (readOnlyHint=false) but not destructive. The description adds a key precondition ('active call') and practical rationale (sensitive information). It does not disclose whether the recording pauses immediately or requires an explicit resume, but the sibling 'aircall_resume_recording' implies the flow, and annotations lower the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the verb and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with one parameter and no output schema, the description is adequately complete. It states the operation, precondition, and a use case, which is enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'call_id' with a description, so the description adds no extra semantic value. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pause') and resource ('recording'), and clarifies scope ('on an active call'), which clearly distinguishes it from the sibling tool 'aircall_resume_recording'.
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 a clear usage context ('Useful for sensitive information'), implying when to use it. It does not explicitly state when not to use it or reference the alternative resume tool, but the context is sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe, read-only nature is known. The description adds that it tests 'connectivity and credentials,' which is useful context beyond the annotation. However, it does not disclose details about the response format or potential errors, which is relevant for a connectivity check, though not critical for a simple ping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the core function, the second provides usage context. Every word earns its place, and the purpose is immediately clear. No redundancy or filler is present.
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 extremely simple with no parameters and a clear purpose. The description covers the essential context: what it does and when to use it. While it could mention the nature of the response (e.g., success/failure indication), the lack of an output schema and the trivial nature of a ping tool make this a minor gap. Overall, the description is sufficient for an agent to invoke and interpret the result at a basic level.
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 is not required to explain parameter semantics. The schema coverage is effectively empty, and the baseline for a 0-parameter tool is 4. The description appropriately focuses on the tool's purpose without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Test connectivity and credentials against the Aircall API.' It uses a specific verb and resource, and the 'Use this to troubleshoot the connection' further clarifies its intent. This distinguishes it from all sibling tools, which focus on data operations rather than connectivity checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-to-use instruction: 'Use this to troubleshoot the connection.' It does not explicitly mention alternatives or when not to use it, but given its unique diagnostic purpose, this is sufficient context for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description is not burdened with safety disclosure. The description adds comparative context about flexibility but does not disclose additional behaviors such as result formatting, pagination, or scope limits. 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 two sentences, front-loaded with the action and criteria, and contains no filler. Every word contributes to understanding the tool's purpose and usage.
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 search with well-documented parameters and annotation indicating a read-only operation. The description adequately covers purpose and usage context, though it omits details like return format or pagination, which are not critical given the simplicity and sibling guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the 6 parameters having its own description. The tool description does not add extra meaning beyond what the schema already documents, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Search calls' and lists the searchable dimensions (phone number, tags, user, number). It also explicitly differentiates itself from list_calls, making its purpose clear and distinct among siblings.
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 phrase 'More flexible than list_calls for finding specific calls' provides clear guidance on when to use this tool instead of the alternative, satisfying the when-to-use criterion with an explicit alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds useful return-oriented context by specifying that it includes user and number counts, which is not covered by annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose and key return details without any filler. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only tool with a clear annotation and no output schema, the description is fully adequate. It explains what the tool does and what key data it returns, which is sufficient for an agent to select and 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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details (not needed), and the schema coverage is trivially 100% with no properties to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('Aircall company account') and adds concrete details about the returned information ('including user and number counts'). This distinguishes it from sibling tools that target other entities like users, numbers, or calls.
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 tool's purpose is self-evident as a company-level getter, and it is the only such tool among siblings. However, the description does not explicitly state when to use it versus alternatives or mention any exclusions. Usage is implied rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context by specifying the return format: per-participant sentiment values and the possible value set. This goes beyond the annotation's safety profile, providing insight into what the response contains. It does not introduce any contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately convey the action, the target, and the return value. There is no redundancy or filler. It is front-loaded with the verb 'Get' and the resource, making it efficient and 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 simple one-parameter read-only tool with no output schema, the description provides enough information for an agent to invoke it correctly and understand the expected response shape. The annotations cover the safety profile, and the description covers the functional outcome. No additional context is necessary for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the only parameter, call_id, with a description ('The call ID'), giving 100% schema_description_coverage. The tool description adds no additional parameter-level semantics beyond implying that the call relates to sentiment analysis. Per the baseline rule, with high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving sentiment analysis for a call. It specifies the resource (sentiment analysis), the scope (a call), and the return content (per-participant sentiment values with POSITIVE/NEUTRAL/NEGATIVE). This distinguishes it from sibling tools like get_summary or get_topics, which cover different analytical outputs.
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?
While the description does not explicitly name alternatives or exclusions, the purpose is so specific that the usage context is clear: an agent should use this when it needs per-participant sentiment values for a call. The mention of 'per-participant' helps differentiate it from other call analytics siblings, providing sufficient context without the need for explicit when/when-not statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds the scope 'for all users' and the practical purpose, but does not disclose response format or potential limitations. With annotations covering safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action ('Get availability status for all users') and a second sentence providing use cases. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, read-only tool with no parameters and no output schema. The description fully covers what it does and when to use it, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The baseline for a zero-param tool is 4, and the description does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get availability status for all users' — a specific verb and resource (availability of all users). This clearly distinguishes it from sibling tools like aircall_check_availability (likely for a single user) and aircall_list_users (user list without availability).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'routing calls or finding available agents.' It does not mention exclusions or alternative tools, but the context is clear and sufficient for an agent to decide when to invoke 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?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Get information'. It adds value beyond annotations by disclosing the availability limitation (OAuth or Aircall-built integrations), which is a behavioral constraint not captured in structured metadata. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action and includes a key constraint. Every word earns its place, with no redundancy or vague 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 simple zero-parameter read-only tool, the description is sufficient: it states what it does and the auth prerequisite. It does not enumerate the exact fields returned, but since there is no output schema and the tool is straightforward, this omission is minor and does not impair selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so the baseline is 4. The description adds meaningful context by specifying that the integration is determined by the 'current API credentials', which explains how the tool implicitly resolves its input and enhances understanding 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 retrieves information about the integration tied to the current API credentials. It uses a specific verb ('Get'), specifies the resource ('integration'), and notes the credential dependency, making it distinct from other integration-related tools like aircall_get_config or aircall_get_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear contextual constraint: it is only available for OAuth or Aircall-built integrations, which helps an agent decide whether the tool is usable in their current auth context. However, it does not explicitly compare against alternatives or provide when-not-to-use guidance beyond that availability restriction.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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