Unofficial Dex CRM MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct purpose with clear boundaries, such as dex_create_contact for creation, dex_update_contact for updates, and dex_list_contacts for listing. The actions (add, create, delete, get, list, manage, merge, remove, search, update) are well-defined and target specific resources (contacts, groups, tags, notes, reminders, custom fields), eliminating ambiguity.
Naming Consistency5/5
All tool names follow a consistent 'dex_verb_noun' pattern with snake_case, such as dex_create_contact, dex_update_contact, and dex_delete_contact. This uniformity makes the tools predictable and easy to understand across the entire set.
Tool Count3/5
With 28 tools, the count is borderline high for a CRM server, potentially overwhelming for agents. While the tools cover comprehensive operations, a more streamlined set might improve usability without sacrificing functionality.
Completeness5/5
The toolset provides complete CRUD and lifecycle coverage for all core CRM entities (contacts, groups, tags, notes, reminders, custom fields), including advanced features like merging contacts, managing associations, and searching. No obvious gaps exist for typical agent workflows in this domain.
Average 3.4/5 across 28 of 28 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 full burden for behavioral disclosure. It states this is an update operation, implying mutation, but doesn't describe what happens during updates (e.g., whether changes affect existing data, if it's reversible, permission requirements, or error conditions). The example 'rename it' suggests one behavioral aspect but leaves others undocumented.
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 brief and front-loaded with the core purpose. The parenthetical example adds some context without unnecessary elaboration. However, it could be more structured by explicitly separating the action from the example.
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 complexity (mutation operation with nested parameters, no annotations, no output schema, and 0% schema coverage), the description is inadequate. It doesn't explain what the tool returns, error handling, or the full scope of updatable fields beyond the naming example. For a mutation tool with undocumented parameters, more comprehensive guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions updating 'by ID' which maps to 'customFieldId', and the example 'rename it' hints at the 'name' property within 'custom_field'. However, it doesn't explain the 'type' property or the structure of the 'custom_field' object, leaving significant gaps in 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 ('Update') and resource ('custom field definition'), and specifies it's done by ID. It distinguishes from sibling 'dex_create_custom_field' by focusing on updates rather than creation. However, it doesn't explicitly differentiate from other update tools like 'dex_update_contact' or 'dex_update_group' 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing custom field ID), when not to use it, or how it compares to other update operations in the sibling list. The example 'e.g. rename it' hints at one use case but doesn't establish clear boundaries.
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 a creation operation but doesn't mention permission requirements, whether groups are unique, what happens on duplicate names, rate limits, or what the response contains. This is inadequate for a mutation tool with zero 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 states the core purpose without unnecessary words. It's appropriately sized for a simple creation tool and front-loads the 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 no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It doesn't explain what parameters are needed, what the tool returns, or important behavioral aspects like error conditions or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions neither parameter ('name' or 'emoji'), their purposes, formats, constraints, or examples. The description adds no value beyond what the bare schema provides.
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') and resource ('new group for organizing contacts'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'dex_update_group' or 'dex_delete_group', but the verb 'Create' provides basic 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?
No guidance is provided about when to use this tool versus alternatives like 'dex_update_group' or 'dex_delete_group'. The description doesn't mention prerequisites, constraints, or typical use cases beyond the basic purpose.
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 clarifies that contacts are not deleted, which is useful, but omits critical details like required permissions, whether the operation is reversible, error handling for invalid IDs, or response format.
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 action and adds a clarifying note about non-destruction. There is no wasted verbiage, making it easy 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 mutation tool with no annotations, 0% schema coverage, and no output schema, the description is insufficient. It lacks details on behavioral traits, parameter semantics, error conditions, and return values, leaving significant gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'groupId' and 'contactIds' implicitly but provides no details on format, validation, or examples (e.g., UUIDs, maximum array size). This leaves parameters largely undocumented.
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 ('Remove') and target resources ('contacts from a group'), distinguishing it from deletion tools like dex_delete_contact. However, it doesn't explicitly differentiate from sibling dex_manage_contact_tags, which might also handle group associations indirectly.
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 like dex_update_contact or dex_manage_contact_tags for contact-group management. The description lacks context about prerequisites, such as whether contacts must already be in the group.
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, implying mutation, but doesn't cover permissions needed, whether changes are reversible, rate limits, error conditions, or what happens if only some fields are provided. For a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and parameters, making it easy to scan. Every word earns its place by contributing essential information about the tool's function.
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 this is a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error handling, or response format. For a tool that modifies data, more context about its operation and results is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'groupId', 'name', and 'emoji' as updatable fields, which maps to the three parameters. However, it doesn't explain parameter meanings beyond their names (e.g., what format groupId expects, whether emoji supports Unicode, if name changes affect other references). The description adds minimal value over the bare schema.
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 ('Update') and target ('a group's name or emoji by ID'), making the purpose understandable. It distinguishes this from sibling tools like 'dex_create_group' (creation) and 'dex_delete_group' (deletion), but doesn't explicitly differentiate from other update tools like 'dex_update_contact' or 'dex_update_tag'.
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 doesn't mention prerequisites (e.g., needing an existing group ID), when not to use it, or how it compares to similar update tools for contacts, tags, or custom fields. The description only states what it does, not when to choose it.
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 but lacks behavioral details. It states the action is to add contacts, implying a mutation, but does not disclose permissions required, rate limits, side effects (e.g., if duplicates are allowed), or response format. This is inadequate for a mutation tool with zero 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 with zero waste—front-loaded with the core action and parameters. Every word earns its place, making it easy 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 mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, return values, and usage context, leaving significant gaps 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'group ID' and 'contact IDs' as parameters, aligning with the schema's 'groupId' and 'contactIds', but adds no semantic details like ID formats, constraints, or examples. This provides basic mapping but minimal value beyond the bare schema.
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 ('Add') and resources ('contacts to a group'), specifying it handles one or more contacts via IDs. It distinguishes from sibling 'dex_remove_contacts_from_group' by indicating addition rather than removal, but does not explicitly differentiate from other contact/group tools like 'dex_update_group' or 'dex_manage_contact_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 does not mention prerequisites (e.g., existing group and contacts), exclusions, or comparisons to siblings like 'dex_manage_contact_tags' or 'dex_update_group', leaving usage context 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool creates something, implying a mutation, but doesn't disclose permissions needed, whether the operation is idempotent, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero 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 directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded with the core action.
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, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on behavioral traits, parameter meanings, expected outcomes, or error handling, leaving significant gaps for an AI agent to use 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 description adds no parameter-specific information beyond what the schema provides. With 0% schema description coverage and 1 parameter (a nested object with properties), the baseline is 3 since the schema documents the structure but not the semantics. The description doesn't compensate by explaining what 'name' or 'type' represent or provide examples.
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') and resource ('new custom field definition'), specifying it can be set on any contact. It distinguishes from siblings like dex_update_custom_field or dex_delete_custom_field by focusing on creation, but doesn't explicitly differentiate from other creation tools like dex_create_contact or dex_create_group.
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 doesn't mention prerequisites, when not to use it, or compare with similar tools like dex_update_custom_field for modifications or dex_list_custom_fields for viewing existing fields.
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 optional features (contact linking, recurrence) but fails to address critical aspects like required permissions, whether the operation is idempotent, error conditions, or what the response contains. For a creation tool with mutation implications, 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 highlights key optional features without redundancy. Every word earns its place, making it easy 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 creation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error handling), response format, and detailed usage context, which are essential for an agent to invoke it correctly in a broader workflow.
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 high (83%), so the baseline is 3. The description adds minimal value beyond the schema by mentioning contact linking and recurrence examples, but it doesn't explain parameter interactions (e.g., how dueDate and dueTime relate) or provide additional context for parameters like isComplete.
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 reminder') and mentions optional features ('linked to contacts', 'recurrence'), which distinguishes it from other creation tools like dex_create_contact or dex_create_note. However, it doesn't explicitly differentiate from dex_update_reminder, which might handle similar fields.
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 doesn't mention prerequisites, when not to use it, or how it differs from sibling tools like dex_update_reminder or dex_delete_reminder, leaving the agent to infer usage from context 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. It states this is a creation tool, implying mutation, but doesn't disclose behavioral traits like required permissions, whether the tag is immediately available, if duplicates are allowed, or what happens on failure. For a mutation 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 front-loads the purpose ('Create a new tag') and adds necessary details (parameters and context) concisely. Every word earns its place, making it easy to parse.
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 (mutation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions or error handling, and while it mentions parameters, it lacks details on formats or constraints. For a creation tool, this leaves critical gaps in 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 0%, so the description must compensate. It adds meaning by specifying that 'name' and 'color' are for the tag, with 'color' being optional, which clarifies beyond the bare schema. However, it doesn't explain parameter formats (e.g., color codes), constraints, or examples, leaving gaps in semantics.
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 tag') and the resource ('tag'), specifying it's for categorizing contacts. It distinguishes from sibling tools like dex_update_tag or dex_delete_tag by focusing on creation. However, it doesn't explicitly differentiate from other creation tools like dex_create_group or dex_create_custom_field 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or compare it to sibling tools like dex_manage_contact_tags or dex_update_tag for similar functionality. Usage is implied only by the action and resource.
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 it's an update operation, implying mutation, but lacks details on permissions, side effects, error handling, or response format. This is inadequate for a mutation tool with zero 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 with no wasted words. It's front-loaded with the core action and resource, making it easy 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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It lacks critical information such as what the tool returns, error conditions, or behavioral nuances, leaving significant gaps for an AI agent to use 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 description mentions updating 'name or color by ID,' which aligns with the three parameters (tagId, name, color) but adds minimal semantics beyond the schema. With 0% schema description coverage, it partially compensates by indicating what fields can be updated, but doesn't explain parameter formats 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 clearly states the action ('Update') and resource ('a tag's name or color by ID'), making the purpose understandable. It distinguishes from sibling tools like 'dex_create_tag' and 'dex_delete_tag' by specifying it's for updates, though it doesn't explicitly contrast with other update tools like 'dex_update_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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing tag ID), exclusions, or comparisons to similar tools like 'dex_manage_contact_tags' for tag-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write operation, it doesn't mention authentication requirements, rate limits, error conditions, or what happens on duplicate contacts. It lists supported fields but doesn't explain behavioral aspects like whether all fields are optional or if there are validation rules.
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 efficiently structured as a single sentence that immediately states the purpose and enumerates supported fields. While comprehensive, it could be more front-loaded by emphasizing the core action before listing fields.
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 creation tool with no annotations, no output schema, and a complex nested parameter structure, the description is moderately complete. It covers what fields are supported but lacks information about required fields, response format, error handling, and behavioral constraints that would be important for proper tool invocation.
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?
With 0% schema description coverage and 1 parameter (a complex nested object), the description adds significant value by listing the supported fields: name, company, job title, emails, phone numbers, social profiles, addresses, custom fields, group/tag associations. This provides semantic context beyond the bare schema, though it doesn't explain field formats 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 clearly states the verb 'Create' and resource 'contact', making the purpose explicit. It distinguishes from siblings like 'dex_update_contact' by specifying creation rather than modification, but doesn't explicitly contrast with other creation tools like 'dex_create_group' or 'dex_create_tag'.
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, when to choose this over 'dex_update_contact' for existing contacts, or how it relates to sibling creation tools like 'dex_create_group' or 'dex_create_tag'.
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 retrieval operation, implying it's read-only, but doesn't cover critical aspects like authentication needs, rate limits, error conditions, or response format (e.g., pagination, sorting). 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 two sentences with zero waste. The first sentence directly states the tool's purpose, and the second adds useful context about custom fields without redundancy. 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?
Given the tool's simplicity (0 parameters) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the retrieval returns (e.g., a list of field objects with properties like name, type), potential limitations (e.g., max fields), or behavioral traits. For a tool that likely returns structured data, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though trivial for an empty schema). The description adds no parameter information, which is appropriate here. A baseline of 4 is applied for zero-parameter tools, as there's nothing to document beyond what the schema already indicates (no inputs required).
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 ('Retrieve') and resource ('all custom field definitions'), making the purpose specific and understandable. It adds helpful context about what custom fields are ('allow adding structured data to contacts beyond the built-in fields'), which distinguishes it from general field-related tools. However, it doesn't explicitly differentiate from sibling tools like dex_update_custom_field or dex_delete_custom_field, 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 custom fields must exist), compare it to other listing tools (e.g., dex_list_contacts), or specify use cases (e.g., for reference before creating/updating fields). 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates a reminder, implying a mutation operation, but fails to describe critical behaviors such as error handling (e.g., what happens if the reminderId is invalid), permission requirements, or whether changes are reversible. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 action ('Update a reminder by ID') and follows with a concise list of modifiable attributes. There is no wasted text, making it highly readable and straightforward.
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 (a mutation operation with nested objects and 2 required parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't cover error cases, response format, or behavioral nuances, leaving the agent with incomplete information to invoke the tool reliably in varied contexts.
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 description lists the modifiable fields (text, due date/time, linked contacts, recurrence, completion status, and notification flags), which adds meaningful context beyond the schema's property names. Since schema description coverage is 0%, this compensates well by clarifying what the 'reminder' object can contain, though it doesn't detail the exact structure or constraints like ISO 8601 formats mentioned in the schema.
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 ('Update a reminder by ID') and specifies what can be modified ('Modify text, due date/time, linked contacts, recurrence, completion status, and notification flags'), making the purpose explicit. However, it doesn't explicitly differentiate from sibling tools like 'dex_update_contact' or 'dex_update_note' beyond the resource type, 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, such as when to update a reminder versus creating a new one with 'dex_create_reminder' or deleting one with 'dex_delete_reminder'. It also lacks information on prerequisites, like needing an existing reminder ID, leaving usage context implied at best.
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 tool updates a note, implying mutation, but lacks details on permissions, side effects (e.g., whether updates are reversible), error handling, or response format. The mention of 'meeting_type_id is resolved automatically' adds some context, but overall transparency is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action ('Update a note by ID') and efficiently lists modifiable fields in a single sentence, followed by a clarifying note about meeting_type_id. Every sentence adds value without redundancy, making it appropriately 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 complexity (mutation with nested parameters), lack of annotations, and no output schema, the description is moderately complete. It covers the main action and parameters but misses behavioral details like permissions, error cases, and return values. It's adequate for basic use but lacks depth for full contextual understanding.
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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'note' is an object containing modifiable fields like note text, event_time, meeting_type (with enum values listed), associated contacts, and custom_emoji, clarifying the structure and purpose of nested parameters. However, it doesn't detail the format for 'event_time' or 'contact_id', leaving minor gaps.
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 ('Update a note by ID') and specifies the modifiable fields (note text, event_time, meeting_type, etc.), making the purpose explicit. It distinguishes from sibling tools like 'dex_create_note' and 'dex_delete_note' by focusing on updates, though it doesn't explicitly contrast with 'dex_update_contact' or other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 doesn't mention prerequisites (e.g., needing an existing note ID), exclusions, or comparisons to similar tools like 'dex_create_note' for new notes or 'dex_update_contact' for contact updates, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination and filtering capabilities but fails to describe critical behaviors like rate limits, authentication requirements, error handling, or the structure of the returned data. This leaves significant gaps for an agent to understand operational constraints.
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 efficiently structured with a clear opening sentence followed by specific examples. Each sentence adds practical value, though the examples could be slightly more concise. Overall, it's well-front-loaded and avoids unnecessary verbosity.
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 complexity (6 parameters, nested objects, no output schema, and no annotations), the description is moderately complete. It excels in explaining the 'where' parameter but neglects others and omits behavioral details. For a tool with rich filtering options, more comprehensive guidance on usage and output would be beneficial.
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 description adds substantial value beyond the schema, which has only 50% coverage. It explains the 'where' parameter with specific examples (e.g., 'where.hasBirthday', 'where.isStarred=true'), clarifying usage that isn't fully documented in the schema. However, it doesn't cover other parameters like 'take', 'skip', 'cursor', 'include', or 'select'.
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 ('contacts'), and mentions advanced filtering, pagination, and field selection. However, it doesn't explicitly differentiate from sibling tools like 'dex_search' or 'dex_get_contact', which might have overlapping functionality for retrieving contacts.
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 implied usage through examples (e.g., 'find today's birthdays'), suggesting when to use certain filters, but lacks explicit guidance on when to choose this tool over alternatives like 'dex_search' or 'dex_get_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.
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 filtering capabilities for reminders and contacts (e.g., startDate, endDate, archived status), which adds some context beyond basic search. However, it doesn't cover critical behaviors like pagination (implied by 'take' and 'cursor' parameters but not explained), rate limits, authentication needs, or what the search returns. For a 9-parameter tool with no annotations, this is insufficient.
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 appropriately sized and front-loaded, starting with the core purpose. Both sentences add value: the first defines the search scope, and the second provides entity-specific filtering details. There's no wasted text, but it could be slightly more structured (e.g., bullet points for entity types).
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 complexity (9 parameters, no annotations, no output schema), the description is moderately complete. It covers the tool's purpose and some parameter semantics, but lacks details on behavioral traits (e.g., pagination, errors) and return values. For a search tool with many parameters and no structured support, this leaves gaps that could hinder effective use by an AI 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 description coverage is 0%, so the description must compensate. It adds meaning for 'entity' by listing enum values and their search scopes (e.g., contacts searches name, email, company), and explains filtering for 'archived', 'startDate', 'endDate', and 'isComplete'. However, it doesn't cover 'searchQuery', 'take', 'cursor', or 'enhanced', leaving 5 of 9 parameters undocumented. This partial coverage meets the baseline but doesn't fully compensate for the schema gap.
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 searches across Dex entities by keyword, specifying the verb (search) and resource (Dex entities). It distinguishes itself from sibling tools like dex_list_contacts or dex_get_contact by emphasizing keyword-based search across multiple entity types rather than listing or retrieving specific items. However, it doesn't explicitly contrast with all siblings, so it's not 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 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: for keyword searches across various Dex entities. It implicitly suggests alternatives by specifying entity types (e.g., use this for contacts, groups, etc.), but doesn't explicitly name when not to use it or direct to specific sibling tools like dex_list_contacts for non-search scenarios. This is good guidance but lacks explicit 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?
With no annotations provided, the description carries full burden. It discloses the partial update behavior ('Only included fields are modified; omitted fields remain unchanged'), which is valuable. However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens on success/failure. For a mutation tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the core purpose and partial update behavior. However, the exhaustive field listing creates redundancy with the schema and could be more concise. Some sentences (like the field enumeration) could be trimmed while maintaining clarity.
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 a mutation tool with 2 parameters, complex nested objects, no annotations, and no output schema, the description does well on parameter semantics but lacks behavioral context. It explains what can be updated but not how the update behaves (e.g., validation, error responses). For this complexity level, it's partially complete but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides extensive semantic context beyond the schema: explains the partial update mechanism, lists all supported fields with examples of complex structures (emails array, tags with append/remove operations), and clarifies that 'data' contains the updatable fields. This adds substantial value over the bare schema.
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 'contact by ID', making the purpose explicit. It distinguishes from siblings like dex_create_contact (create) and dex_delete_contact (delete), but doesn't explicitly differentiate from other update tools like dex_update_group or dex_update_tag.
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 on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., needing a valid contact ID), when to choose this over dex_merge_contacts, or when to use sibling tools like dex_manage_contact_tags for tag operations instead. Usage is implied but not explicitly stated.
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 tool is destructive ('permanently delete') and removes all associated data, which is helpful. However, it lacks details on permissions needed, error handling, or confirmation steps, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words, front-loading the key action ('permanently delete a contact by ID') and adding necessary detail about data removal. Every sentence 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 destructive nature, no annotations, and no output schema, the description is adequate but incomplete. It covers the core action and scope but lacks details on outcomes (e.g., success response or error cases), which are important for a deletion 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 description adds meaning by specifying that the contactId parameter is used to identify the contact to delete, which is useful since schema description coverage is 0%. However, it does not provide format details (e.g., expected ID type or length), so it partially compensates but not 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 action ('permanently delete') and the resource ('a contact by ID'), specifying it removes the contact and all associated data. This distinguishes it from sibling tools like dex_update_contact or dex_merge_contacts by emphasizing irreversible deletion.
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 stating it deletes a contact by ID, but does not explicitly guide when to use this versus alternatives like dex_merge_contacts (for combining contacts) or dex_remove_contacts_from_group (for partial removal). It lacks explicit when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses pagination support, which is valuable behavioral context not inferable from the schema alone. However, it lacks details on permissions, rate limits, response format, or error conditions 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?
Two concise sentences with zero waste. First sentence states core purpose, second adds key behavioral detail (pagination). Well-structured 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 read-only tool with 3 parameters and no output schema, the description is minimally adequate. It covers purpose and pagination but misses parameter explanations, response details, and error handling. Completeness is borderline given the lack of 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 0%, so parameters are undocumented in schema. The description mentions 'groupId' implicitly ('specific group') but doesn't explain 'take' (page size) or 'cursor' (pagination token). It adds minimal value beyond what's inferable from parameter names.
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 ('contacts that belong to a specific group'), making the purpose unambiguous. It distinguishes from generic 'dex_list_contacts' by specifying group membership filtering, though it doesn't explicitly contrast with 'dex_search' which might also filter contacts.
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 needing contacts for a particular group, but provides no explicit guidance on when to use this versus 'dex_list_contacts' (all contacts) or 'dex_search' (filtered search). No prerequisites, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that merging is destructive (first contact kept, others presumably removed) and that data is enriched, but lacks details on permissions needed, rate limits, error handling, or what happens to associated data (e.g., notes, tags). More behavioral context is needed for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first explains the core functionality, the second adds capability for multiple groups. It's front-loaded with the primary purpose and appropriately sized.
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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It covers the basic operation but lacks critical context like response format, error conditions, side effects on related entities, or confirmation of what 'enriched' entails. More detail is needed given the 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 description coverage is 100%, so the schema fully documents the parameter structure. The description adds marginal value by explaining that the first ID becomes primary and data is merged from others, but doesn't clarify semantics beyond what the schema provides (e.g., order significance, data precedence rules).
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 ('merge'), the resource ('duplicate contacts'), and the outcome ('into one'). It distinguishes from siblings like dex_update_contact or dex_delete_contact by focusing on consolidation rather than modification or removal.
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 handling duplicate contacts but doesn't explicitly state when to use this tool versus alternatives like dex_update_contact for modifying a single contact or dex_delete_contact for removing unwanted duplicates. No prerequisites 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?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: 'permanently delete' implies irreversible mutation, and 'removes the timeline entry from all associated contacts' explains side effects. However, it lacks details on permissions, error handling, or confirmation steps, leaving gaps for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste: the first states the core action, and the second adds critical side-effect information. It's front-loaded and efficiently structured, 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?
Given the tool's complexity (destructive mutation with side effects), no annotations, and no output schema, the description is incomplete. It covers the action and scope but misses details like return values, error cases, or authentication needs. It's adequate as a minimum but has clear gaps for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter with 0% description coverage, so the description must compensate. It adds meaning by specifying 'noteId' as the identifier for deletion, though it doesn't detail format or sourcing. Since there's only one parameter, the baseline is high, but it doesn't fully explain the parameter beyond its role.
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') and resource ('a note by ID'), and distinguishes it from siblings like 'dex_update_note' (modify) and 'dex_create_note' (create). It adds scope by mentioning removal from 'all associated contacts,' which is not obvious from the name alone.
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 is provided. It doesn't mention prerequisites (e.g., needing the note ID from another operation) or warn against misuse (e.g., irreversible deletion). The context is implied from the action, but no alternatives or exclusions are stated.
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 mentions retrieval of profile data but lacks details on behavioral traits such as authentication needs (implied but not stated), rate limits, error conditions, or response format. This is a significant gap 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 front-loads the key action and details. There is no wasted text, and it directly communicates the tool's purpose and scope 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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and data retrieved but lacks behavioral context (e.g., authentication, errors) and output details, which are needed for full understanding despite the low complexity.
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 no parameter information is needed. The description does not add parameter semantics, but this is acceptable given the baseline. It implies no inputs are required, which aligns with 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 specific action ('Retrieve') and resource ('profile of the currently authenticated user'), and distinguishes it from sibling tools by focusing on the current user rather than contacts, groups, or other entities. It specifies what information is included (name, email, time zone, subscription plan).
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 by mentioning 'currently authenticated user,' suggesting it should be used when needing the caller's own profile. However, it does not explicitly state when to use this tool versus alternatives (e.g., dex_get_contact for other users) or any prerequisites like authentication requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the action is 'permanently delete' (indicating irreversibility and mutation) and affects 'all contacts' (scope impact). However, it does not mention permissions, rate limits, or error conditions, leaving gaps for a 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.
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 action ('permanently delete') and adds necessary detail about scope. Every word earns its place with no redundancy or fluff, 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 destructive tool with no annotations and no output schema, the description is minimal but adequate. It covers the main action and impact, but lacks details on permissions, confirmation steps, or return values. Given the complexity of deletion, more behavioral context would improve 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 schema has 0% description coverage for its single parameter 'customFieldId', but the description compensates by clarifying that this parameter identifies the custom field to delete and that deletion removes values from contacts. This adds meaningful context beyond the bare schema, though it could specify format or source constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('permanently delete') and resource ('a custom field'), and distinguishes it from siblings like 'dex_update_custom_field' or 'dex_list_custom_fields' by emphasizing irreversible removal. It adds context about the effect on contacts, which is not obvious from the name alone.
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 custom field needs to be removed entirely, but does not explicitly state when to use this versus alternatives like 'dex_update_custom_field' for modifications or warn against misuse. It provides basic context but lacks explicit guidance on prerequisites 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a destructive action ('permanently delete') and clarifies side effects (contacts are not deleted), which is useful. However, it lacks details on permissions, error conditions, or confirmation requirements, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and efficient, with zero waste. The first sentence states the core action, and the second clarifies side effects, both earning their place without 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?
Given the tool's complexity (a destructive deletion with no annotations and no output schema), the description is incomplete. It covers the main action and side effects but omits parameter explanations, error handling, and return values, making it adequate but with clear gaps for safe agent 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?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It does not mention the 'groupId' parameter at all, failing to add any meaning beyond the schema. The baseline is 3 because the schema coverage is low, but the description does not provide parameter details, resulting in a minimal score.
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') and resource ('a group'), and distinguishes it from sibling tools like 'dex_update_group' or 'dex_create_group' by emphasizing deletion. It also clarifies what happens to related resources ('contacts in the group are not deleted'), which adds precision.
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 context by specifying that contacts are not deleted, suggesting this tool is for group removal only. However, it does not explicitly state when to use this versus alternatives like 'dex_remove_contacts_from_group' or provide prerequisites (e.g., group must exist), so it lacks full guidance on exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the deletion is permanent, and for recurring reminders it stops all future occurrences. However, it doesn't mention permission requirements, error conditions, or what happens to associated data, leaving some gaps for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core action, the second addresses an important edge case. It's front-loaded with the primary purpose and wastes no 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?
For a destructive tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the permanence and recurring reminder behavior well, but lacks information about permissions, error handling, and what the tool returns. Given the complexity of a delete operation, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explicitly mention the 'reminderId' parameter or provide any details about its format or where to obtain it. The description adds no parameter-specific information beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('permanently delete') and resource ('a reminder'), and distinguishes itself from siblings by addressing the special case of recurring reminders. It goes beyond a simple tautology by explaining the effect on recurring occurrences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to delete reminders, including handling recurring ones), but it doesn't explicitly mention when not to use it or name specific alternatives. However, the sibling list includes 'dex_update_reminder' as a potential alternative for modifying rather than deleting.
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: the deletion is 'permanent' (irreversible) and has side effects ('removed from all contacts it was assigned to'), which is crucial for a destructive operation. However, it does not mention permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the action and permanence, the second explains the side effect. It is front-loaded with the core purpose and efficiently conveys necessary 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 a destructive tool with no annotations and no output schema, the description is reasonably complete: it covers purpose, permanence, and side effects. However, it lacks details on permissions, error cases, or confirmation requirements, which would be helpful for safe invocation.
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 1 parameter with 0% description coverage, so the description must compensate. It clarifies that 'tagId' refers to the tag to be deleted and implies it identifies a specific tag, but does not specify format or sourcing details. This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('permanently delete') and the resource ('a tag'), and distinguishes it from siblings by specifying the effect on contacts ('removed from all contacts it was assigned to'), unlike other delete tools (e.g., dex_delete_contact, dex_delete_group).
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 deleting tags, but does not explicitly state when to use this tool versus alternatives (e.g., dex_update_tag for modification or dex_manage_contact_tags for tag management). It provides some context about the effect on contacts, but lacks explicit guidance on prerequisites 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by specifying required fields (event_time) and explaining automatic resolution of meeting_type_id. However, it lacks details about permissions needed, rate limits, error conditions, or what happens on success (e.g., returns a note ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with four sentences that each add value: purpose statement, required field, meeting_type explanation, and contact association method. There's no wasted text, and information is front-loaded appropriately for a creation 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?
For a creation tool with no annotations and no output schema, the description does well by explaining required parameters, enum values, and data relationships. However, it doesn't describe what the tool returns (e.g., created note ID) or potential error conditions, which would be helpful given the lack of structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully compensate. It successfully adds meaning beyond the schema by explaining: event_time requires ISO datetime format, meeting_type categories and their purpose, automatic resolution of meeting_type_id, how to associate contacts via timeline_items_contacts array, and that note text goes in the 'note' field. This provides comprehensive parameter guidance.
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 ('Create a new note or timeline entry') and distinguishes it from siblings like dex_update_note (for updates) and dex_delete_note (for deletion). It specifies the resource being created and the type of entry, 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 provides clear context by stating 'Requires event_time' and listing meeting_type categories, which helps guide when to use this tool. However, it doesn't explicitly mention when NOT to use it or name alternatives like dex_update_note for modifying existing notes, leaving some room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: the three action types, that 'create_and_assign' reuses existing tags with the same name, and that actions work on tag-contact associations. It could improve by mentioning potential side effects (e.g., whether operations are atomic), error conditions, or rate limits, but covers core functionality adequately.
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 and front-loaded: the first sentence establishes the core purpose, followed by a bullet-like breakdown of actions with specific behaviors. Every sentence adds essential information with zero waste or 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 mutation tool with 5 parameters, 0% schema coverage, and no output schema, the description provides adequate context about actions and parameter mapping but lacks details on return values, error handling, permissions required, or whether operations are idempotent. It's minimally viable but has clear gaps given the complexity.
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?
With 0% schema description coverage for 5 parameters, the description compensates well by explaining which parameters relate to which actions: contactIds and tagIds for 'add'/'remove', contactId and tagNames for 'create_and_assign'. It clarifies that 'create_and_assign' works with a single contact, which isn't obvious from the schema alone. However, it doesn't fully document all parameter requirements or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Manage tag-contact associations' and specifies three distinct actions (add, remove, create_and_assign) with precise verbs and resources. It distinguishes itself from sibling tools like dex_create_tag (which only creates tags) and dex_update_contact (which modifies contact data rather than tag associations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use each action type (e.g., 'add' for existing tags, 'create_and_assign' for new tags with reuse behavior). However, it doesn't explicitly state when NOT to use this tool versus alternatives like dex_create_tag for standalone tag creation or dex_update_contact for other contact modifications, nor does it mention prerequisites like needing valid contact/tag IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: automatic fetching of notes/timeline entries, inclusion in response under 'notes' key, pagination handling for notes, and default values for parameters. It doesn't mention rate limits, authentication needs, or error conditions, but covers core operational behavior adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste - each sentence adds critical information: core functionality, notes behavior, and pagination details. The description is front-loaded with the main purpose 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 read operation with 3 parameters and no output schema, the description provides good coverage of what the tool does and how it behaves. It explains the response structure (includes notes under 'notes' key) and pagination behavior. However, without annotations or output schema, it could benefit from mentioning error cases or response format details beyond notes.
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 67% (2 of 3 parameters have descriptions). The description adds meaningful context beyond the schema: it explains that notes are automatically fetched and included under a 'notes' key, clarifies the relationship between notesLimit and pagination, and mentions the default value for notesLimit. This compensates well for the partial 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 ('Retrieve a single contact by ID') and distinguishes it from sibling tools like 'dex_list_contacts' (which lists multiple contacts) and 'dex_search' (which searches contacts). It also specifies the resource ('contact') and includes unique behavior about fetching notes.
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 context by specifying it's for retrieving a single contact by ID, which differentiates it from list/search operations. However, it doesn't explicitly state when NOT to use this tool or mention alternatives like 'dex_list_contacts' for multiple contacts or 'dex_search' for filtered searches.
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:

[![unofficial-dex-mcp MCP server](https://glama.ai/mcp/servers/byndcloud/unofficial-dex-mcp/badges/card.svg)](https://glama.ai/mcp/servers/byndcloud/unofficial-dex-mcp)

Score Badge

Copy to your README.md:

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

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