armavita-quo-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources like contacts, calls, messages, phone numbers, users, and webhooks, with clear action distinctions (e.g., create_contact vs. update_contact). However, some potential overlap exists between list_calls and list_conversations, as calls might be part of conversations, which could cause minor confusion for agents.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_contact, list_calls, get_user, and send_text. All tools use snake_case with clear verbs (create, delete, get, list, update, send), making them predictable and easy to understand.
Tool Count4/5
With 21 tools, the count is slightly high but reasonable for a comprehensive CRM/communication platform like Quo, covering contacts, calls, messages, phone numbers, users, and webhooks. It feels a bit heavy but not excessive, as each tool serves a specific function in the domain.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for the domain, including create, get, list, update, and delete operations for contacts, calls, messages, phone numbers, users, and webhooks. There are no obvious gaps; agents can perform core workflows like managing contacts, handling calls, and sending messages without dead ends.
Average 3.3/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create' implies a write/mutation operation, it doesn't specify permissions required, whether the operation is idempotent, what happens on duplicate contacts, or what the response contains. For a mutation tool with zero annotation coverage, this represents a significant gap in 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, efficient sentence that states the core purpose without unnecessary elaboration. It's appropriately sized for a straightforward creation operation and front-loads the essential information with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like error conditions, response format, or system constraints. Given the complexity of creating a contact with multiple optional fields and no structured output documentation, the description should provide more contextual 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%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for when the schema does the heavy lifting of parameter documentation.
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 ('Create a new contact') and the resource ('in the Quo workspace'), which provides a specific verb+resource combination. However, it doesn't differentiate from its sibling 'update_contact' or explain how this differs from other contact-related operations, keeping it from 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 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 like 'update_contact' or 'get_contact'. There's no mention of prerequisites, constraints, or appropriate contexts for creating a contact versus other operations, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't describe traits like whether it's read-only, requires authentication, has rate limits, returns structured data or files, or handles errors. For a tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. No unnecessary details or redundancy are present, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'recordings' means in terms of return values (e.g., list of files, metadata, or both), error conditions, or behavioral constraints. For a tool that likely returns data, this leaves critical gaps 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?
The schema description coverage is 100%, with the parameter 'callId' documented as 'Call ID (AC...)'. The description adds no additional meaning beyond this, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but no extra value is provided.
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 ('Get') and resource ('recordings for a specific call'), making the purpose understandable. It distinguishes from siblings like 'get_call' or 'get_call_transcription' by focusing on recordings. However, it lacks specificity about what 'recordings' entails (e.g., audio files, metadata, or both), preventing 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 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 doesn't mention prerequisites (e.g., whether the call must have recordings enabled), differentiate from similar tools like 'get_call' (which might include recordings), or specify use cases. This leaves the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get[s] a specific message by its ID,' implying a read operation, but doesn't cover aspects like authentication needs, rate limits, error handling (e.g., for invalid IDs), or return format. This leaves significant gaps for a tool with no annotation coverage.
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, making it highly concise and front-loaded. It efficiently conveys the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is minimal but incomplete. It lacks context on usage, behavioral traits, and output details, which are needed for effective tool invocation despite the straightforward nature.
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 description coverage is 100%, with the 'id' parameter documented as 'Message ID (AC...)' in the schema. The description adds no additional meaning beyond this, such as format details or examples, but since the schema provides adequate 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.
Purpose4/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 resource ('a specific message by its ID'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_messages' or 'get_contact', which would require mentioning it retrieves a single message rather than listing or fetching contact-related data.
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 doesn't mention scenarios like needing a single message's details, prerequisites such as having a message ID, or exclusions like not using it for bulk retrieval (where 'list_messages' might be better).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get details'), implying it's non-destructive, but doesn't cover aspects like authentication requirements, rate limits, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get details') and resource. It avoids redundancy and wastes no words, though it could be slightly more structured by separating purpose from included details. Overall, it's appropriately concise for a simple lookup 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?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and what details are returned, but lacks context on usage, behavioral traits, or output structure. For a read-only tool, this is borderline viable but leaves room for improvement in guiding an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantic context beyond the input schema, which has 100% coverage for the single parameter 'phoneNumberId'. It clarifies that the ID corresponds to a 'specific phone number', but doesn't provide additional details like format examples or usage tips. With high schema coverage, the baseline score of 3 is appropriate as the schema does most of the work.
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 'Get details' and the resource 'specific phone number by ID', making the purpose evident. It also specifies what details are included (users, restrictions, forwarding settings), which adds clarity. However, it doesn't explicitly differentiate from sibling tools like 'list_phone_numbers' or 'get_user', which could help an agent choose between them.
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 doesn't mention prerequisites (e.g., needing a phone number ID), exclusions, or compare it to sibling tools like 'list_phone_numbers' for browsing or 'get_user' for user-related phone info. This lack of context could lead to incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't describe traits like whether it's read-only, requires authentication, handles errors, or returns data format. For a tool with no annotations, this is a significant gap in 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, efficient sentence with no wasted words. It's front-loaded with the core action, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'voicemail' entails (e.g., audio file, metadata) or behavioral aspects, leaving gaps for a tool that likely returns media data. More context is needed for full comprehension.
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, with 'callId' documented as 'Call ID (AC...)'. The description doesn't add any parameter details beyond this, such as format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 'voicemail for a call', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'get_call_recordings' or 'get_call_transcription', which might also retrieve call-related media, so it's not fully distinguished.
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 doesn't mention prerequisites, such as needing a call with voicemail, or compare it to siblings like 'get_call' or 'get_call_recordings', leaving the agent to infer 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool lists calls but doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (implied by 'pageToken' but not explained), or what the output format looks like. This leaves significant gaps for an agent to understand how to use it effectively.
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 directly states the tool's purpose without any wasted words. It's appropriately sized and 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like safety, authentication, or output format, and while the schema covers parameters, the overall context for an agent to use this tool correctly is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema—it doesn't explain parameter relationships, constraints, or usage nuances. The baseline of 3 is appropriate when the schema does all the work.
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 ('List') and resource ('calls'), and specifies the filtering criteria ('for a specific phone number and participant'). However, it doesn't differentiate from sibling tools like 'get_call' or 'list_conversations', which reduces the score from a perfect 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 like 'get_call' (for a single call) or 'list_conversations' (for broader conversation listing). There's no mention of prerequisites, exclusions, or comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation but doesn't mention whether it's idempotent, what permissions are required, whether partial updates are allowed, what happens to unspecified fields (preserved or cleared), or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states the core purpose without any wasted words. It's appropriately sized for a straightforward update operation and is front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens during the update (e.g., validation, error conditions), what the return value contains, or how to handle complex nested structures like phoneNumbers and emails arrays. The agent would need to guess about important behavioral aspects.
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 description coverage is 100%, with all parameters well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., format requirements, constraints, or examples). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing contact by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'create_contact' beyond the obvious 'update' vs 'create' distinction, nor does it mention what fields can be updated compared to other tools like 'get_contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 like 'create_contact' for new contacts or 'delete_contact' for removal. It doesn't mention prerequisites (e.g., needing an existing contact ID), nor does it specify which fields are optional versus required beyond the schema's 'id' requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation with filtering, but doesn't describe pagination behavior (implied by 'pageToken' parameter), rate limits, authentication requirements, or what the return format looks like (e.g., list of contact objects). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 front-loads the core purpose ('List contacts in the Quo workspace') and adds a useful qualifier ('with optional filtering'). There is no wasted verbiage, repetition, or structural issues—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 no annotations and no output schema, the description is minimally adequate for a list tool with full parameter documentation in the schema. It covers the basic purpose but lacks behavioral details (e.g., pagination, return format) and usage guidelines. For a tool with 3 parameters and no structured safety or output information, it should do more to compensate, but the clear purpose and concise structure keep it from being inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (maxResults, pageToken, externalIds). The description adds minimal value beyond the schema by mentioning 'optional filtering', which loosely maps to 'externalIds' but doesn't provide additional syntax or usage context. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
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 ('List') and resource ('contacts in the Quo workspace'), providing a specific verb+resource combination. It distinguishes from siblings like 'get_contact' (singular retrieval) and 'create_contact'/'update_contact'/'delete_contact' (mutations), but doesn't explicitly differentiate from other list tools like 'list_calls' or 'list_users' beyond the resource type.
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 mentions 'optional filtering' but provides no guidance on when to use this tool versus alternatives. It doesn't specify prerequisites, when to choose 'list_contacts' over 'get_contact' for individual retrieval, or how it relates to other list tools like 'list_users' for different resource types. No explicit when/when-not or alternative recommendations are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions ordering ('Ordered by most recent activity') which is valuable, but fails to describe pagination behavior (implied by pageToken parameter), rate limits, authentication requirements, or what constitutes 'inactive' conversations. For a list operation with 9 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - two sentences that efficiently convey the core functionality and key behavioral trait (ordering). Every word earns its place, with no redundancy or unnecessary elaboration. The structure is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with 9 well-documented parameters but no annotations or output schema, the description provides adequate but incomplete context. It covers the basic purpose and ordering behavior, but lacks guidance on usage scenarios, pagination details, and response format. The absence of output schema means the agent doesn't know what data structure to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description adds marginal value by mentioning the three main filter categories (phone number, user, date range) and the ordering, but doesn't provide additional semantic context beyond what's in the parameter descriptions. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'conversations', making the purpose immediately understandable. It distinguishes itself from other list tools like list_calls or list_messages by specifying the conversation resource. However, it doesn't explicitly differentiate from potential overlapping tools beyond the resource name.
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 doesn't mention prerequisites, compare with other conversation-related tools (none exist in siblings), or indicate when filtering is appropriate versus other list operations. The agent must infer usage from the parameter descriptions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'List all' implies a read operation, it doesn't specify whether this returns all numbers at once or uses pagination, what format the output takes, whether there are rate limits, or what permissions are required. The description provides basic functionality but lacks important behavioral context for a tool with no annotation coverage.
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 communicates the core functionality without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information. Every word earns its place in conveying what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description provides basic functionality but lacks important context. Without annotations, it should ideally mention that this is a read-only operation, describe the output format, and provide usage guidance. The description is minimally adequate but leaves gaps that could help an agent use the tool more effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single optional parameter. The description doesn't mention the 'userId' filter parameter at all, nor does it provide any additional context about parameter usage beyond what's in the schema. This meets the baseline for high schema coverage but adds no extra value.
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 ('List all phone numbers') and resource ('in the Quo workspace'), including additional details about what information is included ('with their users and settings'). It distinguishes from sibling tools like 'get_phone_number' (singular) by indicating it returns multiple items, but doesn't explicitly differentiate from other list tools like 'list_calls' or 'list_users' beyond the resource type.
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 about when to use this tool versus alternatives. The description doesn't mention when this tool is appropriate versus using 'get_phone_number' for a specific number, or how it relates to other list tools. There's no context about prerequisites, permissions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation but doesn't cover important aspects like pagination, rate limits, authentication requirements, or what 'configured' implies (e.g., active vs. inactive webhooks). This leaves significant gaps for a tool that likely returns sensitive configuration data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and the description's minimalism, this is incomplete for a tool that likely returns structured webhook data. The agent lacks information about return format, error conditions, or behavioral constraints, which are critical for proper invocation in a real-world context.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here, but doesn't compensate for any gaps since there are none. A baseline of 4 is given for zero-parameter tools with complete schema coverage.
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 'List all configured webhooks' clearly states the verb ('List') and resource ('configured webhooks'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_calls' or 'list_contacts' beyond the resource name, 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 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 doesn't mention prerequisites, context for webhook management, or how it relates to other webhook-related tools (though none are listed as siblings), leaving the agent 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions plan restrictions but lacks critical details such as whether this is a read-only operation, potential rate limits, authentication needs, or what the summary format entails (e.g., bullet points, paragraphs). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get an AI-generated summary of a call') and includes essential context ('Business/Scale plans only') without unnecessary words. Every part of the sentence adds value, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns structured data (an AI-generated summary). It fails to explain what the output looks like (e.g., text format, length, key points) or any error conditions, leaving the agent with insufficient context to handle responses effectively.
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 description coverage is 100%, with the single parameter 'callId' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. This meets the baseline score when schema coverage is high.
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 ('Get an AI-generated summary') and resource ('of a call'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_call' or 'get_call_transcription' that also retrieve call-related information, preventing 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?
The description provides some usage context by specifying 'Business/Scale plans only,' which indicates eligibility requirements. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_call' (which might return raw data) or 'get_call_transcription' (which might provide verbatim text), leaving the guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions plan restrictions but doesn't cover critical aspects like authentication needs, rate limits, error conditions, or what the transcription output looks like (e.g., text format, timestamps). For a read operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes essential qualification without unnecessary elaboration. Every word earns its place, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving transcriptions likely involves structured data) and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain the return format, error handling, or behavioral traits, leaving the agent under-informed for proper 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 description coverage is 100%, with the single parameter 'callId' fully documented in the schema as 'Call ID (AC...)'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 without compensating or detracting.
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 ('Get') and resource ('transcription of a call'), making the purpose immediately understandable. It distinguishes from siblings like 'get_call' or 'get_call_summary' by specifying transcription retrieval. However, it doesn't specify verb tense or format details, keeping it at 4 rather than 5.
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 some usage context with the parenthetical '(Business/Scale plans only)', indicating plan restrictions. However, it doesn't explicitly state when to use this versus alternatives like 'get_call' or 'get_call_recordings', nor does it mention prerequisites or exclusions beyond the plan limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List all users') but doesn't describe how the listing works—e.g., pagination, sorting, filtering, or response format. This leaves gaps in understanding the tool's behavior beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently conveys the essential information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate for a basic list operation. However, it lacks details on behavioral aspects like output format or limitations, which could be important for an agent to use it effectively. It meets the minimum viable standard but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it also doesn't compensate for any gaps since there are none. A baseline of 4 is given as it meets expectations for a parameterless tool.
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 ('List') and resource ('all users in the Quo workspace'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_user' or 'list_contacts', which would require a more specific scope or distinction.
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 'get_user' for individual user details or 'list_contacts' for a different resource type. It lacks context about prerequisites, permissions, or typical use cases, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation ('Get'), which is clear, but doesn't disclose behavioral traits like error handling (e.g., what happens if ID is invalid), authentication needs, rate limits, or response format. The description is minimal and lacks context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero waste. It's appropriately sized and front-loaded, making it easy to understand quickly.
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 low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, error handling, or output, which could be helpful for an agent. It meets the minimum viable threshold but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'id' documented as 'Contact ID'. The description adds no additional meaning beyond what the schema provides (e.g., format examples, validation rules). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 resource ('a specific contact'), specifying it's by ID. It distinguishes from siblings like list_contacts (which retrieves multiple) but doesn't explicitly differentiate from get_contact_custom_fields or other get_* tools that retrieve different resources.
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 a specific contact identified by ID, but doesn't provide explicit guidance on when to use this versus alternatives like list_contacts (for multiple contacts) or get_contact_custom_fields (for contact metadata). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation ('Get'), but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the user ID is invalid. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant information or unnecessary elaboration.
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 read tool with 1 parameter and 100% schema coverage, the description is adequate but minimal. It lacks output details (no output schema provided) and behavioral context, which could be important for an agent. It meets minimum viability but has clear gaps in operational 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 the parameter 'userId' documented as 'User ID (US...)'. The description adds that it's for 'a specific user by ID', which aligns with the schema but doesn't provide additional meaning like format examples or constraints beyond what's in the schema. Baseline 3 is appropriate given high schema coverage.
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 ('Get') and resource ('a specific user by ID'), and specifies the returned fields (email, name, role, picture). It distinguishes from siblings like 'list_users' by focusing on a single user, but doesn't explicitly contrast with other user-related tools beyond that.
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 a specific user's details by ID, but doesn't explicitly state when to use this vs. alternatives like 'list_users' for multiple users or other get_* tools for different resources. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: returns messages 'in chronological order' and 'with pagination', which are crucial for understanding output behavior. It doesn't mention rate limits, authentication needs, or error conditions, but covers ordering and pagination well for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and key behavioral details (chronological order, pagination). Every word earns its place with zero waste, making it easy to parse quickly.
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 read operation with 6 parameters and no output schema, the description covers purpose, ordering, and pagination adequately. However, it lacks details on return format, error handling, or examples, which could help given the complexity. With no annotations, it's minimally complete but leaves gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no parameter-specific semantics beyond implying filtering by phone number and participants. It doesn't explain parameter interactions or provide additional context, so it meets the baseline for high schema coverage without adding value.
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 ('List') and resource ('messages'), specifying the scope ('for a specific phone number and conversation participant'). It distinguishes from siblings like 'get_message' (singular) and 'list_conversations', but doesn't explicitly contrast with 'send_text' or other messaging tools. The purpose is specific but could better differentiate from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'phone number and conversation participant', suggesting it's for retrieving message history in a specific context. However, it doesn't explicitly state when to use this versus alternatives like 'list_conversations' or 'get_message', nor does it provide exclusions or prerequisites. Usage is implied but not clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core action (sending SMS) and format requirements (E.164), but lacks critical behavioral details such as rate limits, authentication needs, error handling, whether messages are queued or sent immediately, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded (core purpose first) and zero waste. Every sentence adds value: the first states what the tool does and key format requirements, the second clarifies the 'from' field options. No redundant or vague phrasing.
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 complexity (a mutation with 4 parameters, no output schema, and no annotations), the description is minimally complete. It covers the basic purpose and parameter formats but lacks behavioral context (e.g., side effects, error cases) and output details. Without annotations or output schema, the description should do more to compensate, making it adequate but with clear 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning E.164 format for 'to' and clarifying that 'from' can be a phone number ID or E.164 number, which slightly reinforces the schema but doesn't provide new semantic insights. This meets the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('send an SMS text message'), resource ('from a Quo phone number to a recipient'), and distinguishes it from siblings like 'get_message' or 'list_messages' which are read operations, not send operations. It uses precise terminology like 'SMS text message' and 'E.164 format' to define 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 ('to send an SMS text message') and implicitly distinguishes it from sibling tools like 'get_message' (for reading) or 'create_contact' (for contact management). However, it doesn't explicitly state when NOT to use it (e.g., for voice calls or other message types) or name specific alternatives, keeping it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves details (implying a read operation) and lists specific attributes returned, but does not mention behavioral traits like error handling, authentication needs, rate limits, or what happens if the call ID is invalid. It adds some context but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes key details without any wasted words. Every part of the sentence earns its place by specifying the action, resource, identifier, and included attributes.
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 (single parameter, no output schema, no annotations), the description is reasonably complete for a read operation. It specifies what details are included, but could be more complete by mentioning the return format or potential errors, though this is not critical for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema fully documenting the single parameter 'callId' as a string with format 'AC...'. The description adds no additional parameter semantics beyond what the schema provides, 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 clearly states the specific action ('Get details'), resource ('a specific call'), and key attributes included ('duration, status, direction'), distinguishing it from siblings like 'list_calls' (which lists multiple calls) and 'get_call_summary' (which presumably provides a summary rather than full details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed information about a specific call is needed, but does not explicitly state when to use it versus alternatives like 'get_call_summary' or 'list_calls'. It provides clear context (by ID) but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the destructive nature of the operation ('THIS IS DESTRUCTIVE'), which is crucial for a deletion tool. However, it lacks details on permissions required, whether deletion is reversible, or what happens to associated data, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, front-loading the core purpose ('Delete a contact by ID') and following with a critical warning. Every word earns its place, making it efficient and easy to parse without unnecessary elaboration.
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 complexity as a destructive operation with no annotations and no output schema, the description is minimally adequate. It covers the destructive nature but lacks information on return values, error conditions, or system impacts, which are important for such a high-risk 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 description coverage is 100%, with the 'id' parameter fully documented in the schema as 'Contact ID to delete'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, 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 clearly states the specific action ('Delete') and resource ('a contact by ID'), distinguishing it from sibling tools like 'create_contact', 'get_contact', and 'update_contact'. It precisely communicates the tool's function without ambiguity.
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 with the warning 'THIS IS DESTRUCTIVE — use with caution', which implicitly guides usage by highlighting risk. However, it does not explicitly state when to use this tool versus alternatives like 'update_contact' or list tools, nor does it mention prerequisites such as needing the contact ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a list operation, which implies it is read-only and non-destructive, but does not disclose behavioral traits like rate limits, authentication needs, or pagination. The description adds some context about the purpose but lacks operational 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 two concise sentences that are front-loaded with the core purpose and followed by a helpful usage note. Every sentence adds value without redundancy, making it efficient 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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete for a read-only list operation. It explains what the tool does and its utility, though it could benefit from more behavioral details like response format or limitations. The lack of output schema means the description does not cover return values, which is a minor gap.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention parameters, which is appropriate. A baseline of 4 is applied for tools with no parameters, as there is nothing 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 clearly states the specific action ('List all custom contact fields') and resource ('defined in the workspace'), with details on what information is returned ('name, key, type'). It distinguishes this from sibling tools like 'get_contact' or 'list_contacts' by focusing on metadata about custom fields rather than contact data itself.
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 ('Useful for understanding what custom data is tracked on contacts'), which implicitly suggests it should be used before or in conjunction with contact-related operations. However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools.
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:

[![armavita-quo-mcp MCP server](https://glama.ai/mcp/servers/EfrainTorres/armavita-quo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/EfrainTorres/armavita-quo-mcp)

Score Badge

Copy to your README.md:

[![armavita-quo-mcp MCP server](https://glama.ai/mcp/servers/EfrainTorres/armavita-quo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/EfrainTorres/armavita-quo-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EfrainTorres/armavita-quo-mcp'

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