didlogic_mcp

by UserAd

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources like SIP accounts, DIDs, or destinations, with clear boundaries. However, some tools like 'list_country_cities' and 'list_country_cities_in_region' have overlapping functionality that could cause confusion, as both list cities but with slightly different scopes.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., add_allowed_ip, delete_destination, get_balance) throughout the set. There are minor deviations like 'list_country_cities_in_region' being longer than others, but the pattern remains readable and predictable.
Tool Count3/5
With 21 tools, the count is borderline high for a DID/SIP management server, as it includes many specific listing and purchasing tools. While comprehensive, it feels slightly heavy and could be streamlined, but it's not extreme and covers the domain adequately.
Completeness5/5
The tool set provides complete coverage for the DIDLogic domain, including SIP account CRUD, DID purchasing and management, destination handling, call history, transactions, and balance checks. There are no obvious gaps, and agents can perform full lifecycle operations without dead ends.
Average 3.3/5 across 21 of 21 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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 is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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. It describes the return format and example, which adds some behavioral context, but it fails to disclose critical traits: whether this is a creation or update operation (contradicting the name), what permissions are required, if it's idempotent, or any rate limits. The description adds value with the return details but leaves significant 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections for Args, Returns, and Example, which is helpful. However, it is overly verbose: the parameter list duplicates schema information, and the return details are extensive but could be more concise. The opening line 'Creates a SIP account' is misleading and wastes space. It is front-loaded with the contradiction, reducing effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 15 parameters for a mutation tool, the description is incomplete. It covers return values and provides an example, which helps, but it fails to resolve the core contradiction with the tool name, lacks error handling information, and does not specify behavioral constraints like authentication needs. For a complex tool like this, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 15 parameters thoroughly. The description lists parameters with brief explanations (e.g., 'call_limit: maximum call duration in seconds'), but these largely repeat or paraphrase schema descriptions without adding significant new semantics. It provides examples like 'ex: 00' for rewrite_cond, which adds minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Creates a SIP account' but the tool is named 'update_sip_account', creating a direct contradiction. The description does not clarify whether this is actually a creation or update operation, and it fails to distinguish this tool from sibling tools like 'delete_sip_account' or 'get_sip_account'. This is misleading and tautological to the name conflict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as whether an existing SIP account is required for updates, or differentiate from sibling tools like 'list_sip_accounts' or 'delete_sip_account'. Usage context is implied only through parameter documentation, with no explicit when-to-use or when-not-to-use statements.
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 mentions the return message ('IP removed successfully') but lacks details on permissions required, error conditions (e.g., if IP isn't whitelisted), or side effects (e.g., impact on SIP account access). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by parameter and return details. It avoids unnecessary fluff, though the 'Args:' and 'Returns' sections could be integrated more smoothly into a single narrative flow.
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 deletion tool with no annotations and no output schema, the description is incomplete. It lacks critical context like success/failure behaviors, error handling, and security implications (e.g., whether this disables access). The return message is noted, but overall coverage is insufficient 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?
Schema description coverage is 100%, so the schema already documents both parameters ('sipaccount_name' and 'ip') with clear descriptions. The description adds no additional meaning beyond what's in the schema, such as format examples or constraints, but meets the baseline since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('whitelisted IP from a SIP account'), making the purpose immediately understandable. It distinguishes from siblings like 'add_allowed_ip' by specifying removal rather than addition, though it doesn't explicitly contrast with other deletion tools like 'delete_destination' or 'delete_sip_account'.
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. While the description implies it's for removing IPs from whitelists, it doesn't specify prerequisites (e.g., IP must already be whitelisted), exclusions, or when to choose other tools like 'delete_sip_account' for broader account management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Remove') implying a destructive operation, and mentions the return value on success, but lacks critical details: it doesn't specify permissions required, whether the deletion is reversible, error conditions, or side effects. For a destructive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args and Returns sections are structured clearly. However, the 'Args' label is slightly redundant with the schema, and the description could be more efficient by integrating parameter hints into the main text.
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 destructive nature, lack of annotations, and no output schema, the description is incomplete. It covers basic purpose and parameters but misses critical context: error handling, authentication needs, confirmation prompts, or what 'Destination deleted' entails. For a mutation tool in this context, more behavioral and safety information is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('number' and 'id') well-documented in the schema (e.g., 'id' is 'Destination ID from list_destinations'). The description repeats parameter names in the Args section but adds minimal value beyond the schema—it doesn't explain format nuances (e.g., 'number' can be string or integer) or provide examples. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove destination') and target resource ('from DID'), which is specific and unambiguous. It distinguishes from siblings like 'delete_allowed_ip' or 'delete_sip_account' by specifying the resource type (destination vs. allowed IP or SIP account). However, it doesn't explicitly contrast with 'remove_purchased_did', which might cause some confusion about scope differences.
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., that the destination must exist), when not to use it, or how it relates to siblings like 'list_destinations' (which provides the ID) or 'add_destination'. The agent must infer usage from the name and description 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states the destructive action ('Delete') and mentions success response, it lacks critical information: required permissions, whether deletion is reversible, what happens to associated data, error conditions, or rate limits. For a destructive operation with zero annotation coverage, 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 concise with three brief sentences. The purpose is stated upfront, followed by parameter documentation and return value information. However, the 'Args:' and 'Returns:' formatting could be more integrated with the natural language description rather than appearing as separate documentation blocks.
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 destructive operation with no annotations and no output schema, the description is incomplete. It mentions the success response but provides no information about failure modes, error formats, or what constitutes a valid SIP account name. The context signals show this is a single-parameter tool, but the description doesn't adequately address the behavioral implications of a deletion operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single parameter 'name' is fully documented in the schema as 'Name of SIP account'). The description adds no additional parameter information beyond what the schema already provides, so it meets the baseline of 3 for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a SIP account'), providing specific verb+resource combination. However, it doesn't distinguish this tool from sibling deletion tools like 'delete_allowed_ip' or 'delete_destination', which would require explicit differentiation to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for deletion operations, but no indication of which specific scenarios warrant deleting a SIP account versus other resources. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format and example, which is helpful, but lacks critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or error handling. The description does not contradict annotations, but it is insufficient for a mutation-sensitive context.
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 structured with sections for Args, Returns, and an Example, which is organized. However, it includes verbose details in the return explanation and example that could be more succinct, and the front-loaded purpose statement is brief but not maximally efficient. Some sentences, like the detailed return field descriptions, could be condensed without losing 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 the tool has 1 parameter with full schema coverage and no output schema, the description provides a clear purpose, return format, and example, which is adequate for a simple list tool. However, it lacks behavioral context (e.g., safety, limits) and usage guidelines, making it incomplete for optimal agent decision-making in a server with multiple related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'number' documented as 'DID Number'. The description adds minimal value by restating 'DID number in DIDLogic', which is slightly redundant. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description does not significantly enhance parameter understanding beyond 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 verb ('List') and resource ('DID destination'), making the purpose specific and understandable. However, it does not explicitly differentiate this tool from sibling tools like 'get_sip_account' or 'list_sip_accounts', which might also retrieve related information, leaving some ambiguity in sibling differentiation.
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 'list_sip_accounts' or 'get_sip_account', nor does it mention any prerequisites or exclusions. It only describes what the tool does, without contextual usage advice.
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 'Returns a JSON object' with an example, which adds some context on output format, but lacks details on permissions, rate limits, or error handling. This is inadequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by structured sections for args and returns with an example. It's efficient and well-organized, though the example output could be slightly more detailed to enhance clarity without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description provides basic purpose and parameter semantics but lacks comprehensive behavioral details. It's minimally viable for a simple retrieval tool but could improve with more context on usage or errors.
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 meaningful context for the single parameter 'sipaccount_name' by explaining it as 'Name of SIP account', which clarifies its role beyond the schema's title. With 0% schema description coverage and only one parameter, this compensation is effective, though not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get list') and resource ('whitelisted IPs for a SIP account'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_sip_account' or 'list_sip_accounts', which might also retrieve SIP account information, so it falls short of 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. For example, it doesn't mention if this is for retrieving only IP-related data as opposed to other SIP account details available in sibling tools, leaving the agent without context for selection.
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 adds some valuable context: it describes the return format with specific fields, mentions a 403 error case, and provides an example. However, it doesn't cover important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or pagination behavior. The information provided is helpful but incomplete for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with sections for Args, Returns, and Example, but it's somewhat verbose. The parameter explanation could be more concise, and the error information is buried rather than front-loaded. While not excessively long, some sentences don't earn their place efficiently, such as repeating parameter information already in the schema.
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 moderate complexity (single optional parameter, no output schema, no annotations), the description provides adequate but not comprehensive coverage. It explains the return format well with field descriptions and an example, which compensates for the lack of output schema. However, it misses important contextual elements like authentication requirements, rate limits, and clearer differentiation from sibling tools, leaving gaps for 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?
The input schema has 100% description coverage, with the single parameter 'sms_enabled' well-documented in the schema. The description adds minimal value beyond the schema: it restates the parameter name and purpose ('search for DID with SMS functionality') but doesn't provide additional context about how this filtering works or practical usage examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List available countries with DID for purchase on DIDLogic.' It specifies the verb ('List'), resource ('available countries'), and context ('with DID for purchase on DIDLogic'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like list_country_regions or list_country_cities, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that countries with provinces/states can be queried by list_country_regions, but this is buried in a parameter field explanation rather than as explicit usage advice. There's no discussion of prerequisites, alternatives, or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('JSON object with balance in USD') and an example, which adds some context. However, it fails to disclose critical behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or error handling. For a tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: it states the purpose in the first sentence, provides return details in the second, and includes an example output. Every sentence adds value without waste, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output format, but lacks details on authentication, error cases, or integration context. Without annotations or output schema, it should do more to compensate, but it meets the bare minimum for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline of 4 is appropriate as it avoids redundancy and focuses on other aspects, though it doesn't fully earn a 5 since it doesn't explicitly state the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the current DIDLogic account balance.' It specifies the verb ('Get') and resource ('DIDLogic account balance'), making the intent unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_transactions' or 'get_call_history', which might also retrieve financial or account-related data, so it doesn't fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether authentication is required or if it's for real-time balance checks. With sibling tools like 'get_transactions' that might provide related financial data, the lack of comparative guidance is a significant gap.
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 effectively describes what data is returned (the JSON structure with all fields explained), which is good behavioral transparency for a read operation. However, it doesn't mention error conditions, authentication requirements, rate limits, or whether this is a read-only operation (though 'get' implies it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, but becomes verbose with the exhaustive field-by-field explanation of the return object. While comprehensive, this detailed return value documentation might be better suited for an output schema. The example is helpful but lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with 1 parameter and no output schema, the description provides excellent completeness by documenting all return fields with clear explanations. The example adds concrete value. However, without annotations covering safety/behavioral aspects, some gaps remain regarding error handling and operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'name' well-documented in the schema. The description adds minimal value beyond the schema by restating 'name: SIP account name' in the Args section. The baseline of 3 is appropriate since the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details about SIP account' - a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_sip_accounts' or 'update_sip_account', which would be needed for 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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'list_sip_accounts' (for listing multiple accounts) or 'update_sip_account' (for modifying accounts), leaving the agent without context about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some useful context: it describes the return format (JSON object with cities list and fields), mentions a 403 error for disabled API calls, and implies this is for purchase-related queries. However, it doesn't cover important behavioral aspects like whether this is a read-only operation, rate limits, authentication requirements, or what 'available for purchase' entails (e.g., real-time inventory vs. cached data).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by parameter explanations, return format details, error handling note, and an example. Each section adds value, though the parameter explanations are somewhat redundant with the schema. The example is helpful but could be more concise if integrated into the return format description.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose, parameters, return format, and an error case, which is sufficient for basic use. However, it lacks context on behavioral traits (e.g., read-only status, side effects) and doesn't help differentiate from sibling tools, leaving room for improvement in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('country_id' and 'sms_enabled') adequately. The description adds minimal value beyond the schema: it restates 'country_id' as 'ID of country for search' and 'sms_enabled' as 'search for DID with SMS functionality', which is essentially what the schema says. No additional syntax, format details, or constraints are provided, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List of Cities with available DID for purchase in a country'. It specifies the verb ('List'), resource ('Cities'), and scope ('available DID for purchase in a country'), which is more specific than just restating the name. However, it doesn't explicitly differentiate from sibling tools like 'list_country_cities_in_region' or 'list_dids_in_country_city', which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_country_cities_in_region' (for regional filtering) or 'list_dids_in_country_city' (for listing DIDs within a city), nor does it specify prerequisites or exclusions. The only contextual hint is the 403 error note, but this doesn't help with tool selection.
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 pagination behavior and the 5000-record maximum, which are valuable behavioral traits. However, it doesn't mention authentication requirements, rate limits, or whether this is a read-only operation (though 'List' implies reading).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Example) and front-loads the core purpose. However, the detailed return value documentation could be more concise, and some information (like the exact field names) might be better placed in an output schema if available.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (pagination, structured return data) and no output schema, the description provides comprehensive return value documentation including field meanings and an example. This compensates well for the missing output schema, though authentication and error handling context is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description repeats the parameter names but doesn't add meaningful semantic context beyond what's in the schema (e.g., 'page of result starting with 1' vs schema's 'Page for purchases').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'List purchased DIDs in DIDLogic' - a specific verb ('List') with resource ('purchased DIDs') and system context ('in DIDLogic'). However, it doesn't explicitly differentiate this from sibling tools like 'list_dids_in_country_city' or 'get_call_history', which might offer overlapping functionality.
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. With sibling tools like 'list_dids_in_country_city', 'get_call_history', and 'list_countries', there's no indication of when this specific purchase-focused listing is appropriate versus other listing/filtering options.
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 partially succeeds by detailing the return structure and example, including error handling and purchase details. However, it misses critical behavioral aspects: it doesn't clarify if this is a mutating operation (implied by 'purchase'), mention costs or billing implications, rate limits, or authentication requirements, leaving gaps for a tool that likely involves financial transactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with clear sections for Args, Returns, and an Example. It avoids unnecessary fluff, but the example is lengthy and could be summarized more efficiently. Most sentences earn their place by clarifying output semantics, though some redundancy exists with the schema.
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 of a purchase tool with no annotations or output schema, the description is moderately complete. It details the return structure thoroughly, which compensates for the lack of output schema. However, it lacks context on behavioral aspects like mutation effects, costs, or error scenarios, making it adequate but with clear gaps for informed tool 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 100% description coverage, with the parameter 'number' documented as 'DID number for purchase' in E164 format. The description adds minimal value beyond this, restating the parameter name and format without providing additional context like validation rules or examples. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance 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 tool's purpose: 'Purchase DID from DIDLogic'. It specifies the verb ('purchase') and resource ('DID'), making the action explicit. However, it doesn't differentiate from sibling tools like 'list_purchases' or 'remove_purchased_did', which would require explicit comparison to achieve a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., account balance, documentation requirements), nor does it compare to siblings like 'list_dids_in_country_city' for selection or 'remove_purchased_did' for reversal. 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.
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 this is a write operation ('Add'), describes the return format, and provides an example response. However, it doesn't mention important behavioral aspects like authentication requirements, error conditions, rate limits, or whether this operation is idempotent.
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, but includes redundant information. The 'transport' explanation appears twice (in both Args and Returns sections), and the example is quite lengthy. Some sentences could be more 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 write operation with no annotations and no output schema, the description does a good job covering the essentials: purpose, parameters with meaningful explanations, and a detailed return example. The main gaps are lack of error handling information and workflow context with sibling tools.
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 description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the 'transport' parameter's numeric codes (1=SIP address, 4=PSTN, 5=SIP account) with examples, and clarifies the meaning of boolean flags ('callhunt' and 'active'). This goes well beyond what the 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 ('Add a DID destination') and resource ('DID destination'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'list_destinations' or 'delete_destination', which would be needed for 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. There's no mention of prerequisites, when this operation is appropriate, or how it relates to sibling tools like 'list_destinations' or 'delete_destination' in a workflow.
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 that this is a query/read operation (implied by 'Query'), includes pagination behavior details, and reveals the 5000-record maximum limit. However, it doesn't mention authentication requirements, rate limits, error conditions, or whether this is a real-time or historical query. Some behavioral context is provided but key operational details are missing.
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 sized but not optimally structured. It front-loads the purpose but then mixes parameter explanations with return value documentation. The example response is detailed but could be more concise. Some sentences (like the detailed parameter explanations) earn their place, but the organization could be improved for better scannability.
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 9 parameters, 100% schema coverage, no output schema, and no annotations, the description provides good completeness. It covers parameters, return structure with detailed field explanations, pagination behavior, and includes a comprehensive example. The main gaps are lack of authentication/error handling details and no sibling tool differentiation, but for a query tool with good parameter documentation, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining parameter relationships and usage context beyond schema descriptions: it clarifies that 'number' is for incoming calls while 'sip_account' is for outbound calls, explains the call_type enum meanings, and provides format examples. This compensates well for what the schema alone 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 tool's purpose as 'Query Call history in DIDlogic' with specific resource (call history) and context (DIDlogic system). It distinguishes itself from siblings like get_transactions or get_balance by focusing specifically on call records, though it doesn't explicitly contrast with other call-related tools (none appear in sibling list).
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. While it explains parameter usage (e.g., 'sip_account: SIP account name to search for outbound calls'), it doesn't mention prerequisites, constraints, or when other tools might be more appropriate. No explicit when/when-not statements or alternative tool references are included.
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 the return format (JSON object with detailed fields) and includes an example, which helps understand behavior. However, it lacks critical details like pagination, error handling, rate limits, or authentication requirements, leaving gaps for a tool with no annotations.
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 front-loaded with the purpose but becomes verbose by listing all return fields and including a full example. While the example is helpful, the field explanations could be more concise. Some sentences (like the field list) are necessary but lengthy, reducing efficiency.
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 0 parameters, no annotations, and no output schema, the description compensates well by detailing the return structure and providing an example. It covers what the tool does and what to expect in response. However, it misses behavioral aspects like error cases or performance considerations, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter details, so it appropriately focuses on output. It provides extensive semantics for the returned fields (e.g., explaining 'rewrite_enabled' and 'call_limit'), which is valuable beyond 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 tool's purpose: 'List all SIP accounts' with a specific verb ('List') and resource ('SIP accounts'). It distinguishes from siblings like 'get_sip_account' (singular) and 'update_sip_account' by indicating it returns all accounts. However, it doesn't explicitly contrast with other list tools (e.g., 'list_destinations'), leaving some ambiguity.
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., authentication), compare with 'get_sip_account' for single accounts, or specify scenarios where listing all accounts is appropriate. Usage is implied from the name but not articulated.
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 full disclosure burden. It details parameters and return fields, but omits side effects (e.g., overwriting existing accounts, validation failures) that would help an agent understand the tool's behavior completely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long, including a full parameter list and return field list that largely duplicate the input schema. It could be significantly shortened while retaining key information, compressing repeated patterns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 14 parameters, no output schema, and no annotations, the description is thorough: it explains each parameter, all return fields, and provides an example response. This enables an agent to understand how to invoke the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description largely repeats schema descriptions verbatim (e.g., 'password: Password to be used for this SIP account'), adding no new insight beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a new SIP account', specifying the exact action and resource. This distinguishes it from sibling tools like update_sip_account and delete_sip_account, which modify or remove accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage for creating a new account, but lacks guidance on prerequisites or when to choose update or delete instead.
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 clearly indicates this is a destructive operation ('Remove'), but doesn't disclose critical behavioral traits like whether removal is permanent/reversible, authentication requirements, rate limits, error conditions, or side effects. The example response adds some value by showing the return format.
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 front-loaded with the core purpose, but includes extensive return value documentation that could be better handled by an output schema. The example is helpful but lengthy. Some sentences (like the detailed field explanations) could be more concise 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?
For a destructive operation with no annotations and no output schema, the description does provide the return structure via example, which is valuable. However, it lacks important context about the operation's consequences, prerequisites, and error handling. The completeness is adequate but has clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter. The description adds minimal value beyond the schema by specifying the E164 format requirement and clarifying it's for 'removing' (consistent with schema's 'remove from'). With only one parameter, the baseline is appropriately high.
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 ('Remove DID from DIDLogic account') and identifies the resource (DID number). It distinguishes this tool from siblings like 'delete_sip_account' or 'delete_destination' by specifying it's for removing purchased DIDs specifically, not other account elements.
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., DID must be purchased first), exclusions, or compare it to similar tools like 'delete_sip_account'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the return format (JSON object with regions), field details (id, name, short_name), and error behavior (403 indicates disabled API calls). It doesn't mention rate limits, authentication needs, or pagination, but covers key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose statement, args section, returns explanation, error note, and example. It's appropriately sized but could be slightly more concise by integrating the example more tightly. Most sentences earn their place, though the returns section is somewhat redundant with the example.
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 no annotations, no output schema, and 2 parameters with full schema coverage, the description provides good contextual completeness. It covers purpose, parameters, return format, error handling, and includes an example. It lacks details on authentication or rate limits, but is largely sufficient for this read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by briefly mentioning 'search for DID with SMS functionality' for sms_enabled, but doesn't provide additional syntax or format details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'country regions with available DIDs for purchase', specifying the exact scope. It distinguishes from siblings like list_countries (countries vs regions) and list_country_cities (cities vs regions) by focusing on regions with purchasable DIDs.
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 searching for regions with purchasable DIDs, but lacks explicit guidance on when to use this tool versus alternatives like list_countries or list_country_cities. No exclusions or prerequisites are mentioned, though the 403 error note provides some operational context.
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: it returns a JSON object with specific fields (id, name, area_code, count), mentions a 403 error indicates 'disabled API calls for purchase' (implying this tool is related to purchase functionality), and provides an example output. However, it does not cover potential rate limits, authentication needs, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args and Returns sections are structured clearly, and the example is helpful. However, the 403 error note could be integrated more smoothly, and some redundancy exists (e.g., 'Returns a JSON object' is somewhat repetitive with the example).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is mostly complete: it explains the purpose, parameters, return structure with fields, and includes an error note and example. However, it lacks details on authentication, rate limits, or how to handle large result sets, which would enhance completeness for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (country_id, region_id, sms_enabled). The description adds minimal value beyond the schema: it restates 'country_id' and 'region_id' without extra meaning, and clarifies 'sms_enabled' as 'search for DID with SMS functionality', which slightly elaborates on the schema's 'Filter for sms enabled numbers'. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 with specific verbs ('List of Cities with available DID in a region of a country') and distinguishes it from sibling tools like 'list_country_cities' (which presumably lists cities across the entire country) and 'list_country_regions' (which lists regions). It specifies the resource (cities with available DIDs) and scope (within a specific region of a country).
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 lists cities 'in a region of a country' and mentions filtering for SMS functionality, but it does not explicitly state when to use this tool versus alternatives like 'list_country_cities' or 'list_dids_in_country_city'. It provides some guidance through parameter descriptions but lacks explicit when/when-not instructions or named alternatives.
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 the return format (JSON with all whitelisted IPs) and implies this is a write operation that modifies security settings. However, it doesn't mention authentication requirements, rate limits, error conditions, or whether the operation is idempotent—important gaps for a security-related 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 efficiently structured with a clear purpose statement, parameter documentation, and example output—all in four concise lines. Every sentence earns its place: the first states the action, the Args section clarifies inputs, and the Returns/Example provide essential context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no output schema, the description does well by explaining the action, parameters, and return format. However, as a security-modification tool, it should ideally mention permission requirements or side effects. The example output is helpful but doesn't fully compensate for missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds minimal value by repeating the parameter descriptions in the Args section, but does provide an example output that helps understand the tool's effect. With complete schema coverage, the baseline is 3, and the example output justifies a slight bump.
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 ('Whitelist an IP') and target resource ('to a SIP account'), distinguishing it from sibling tools like delete_allowed_ip and get_allowed_ips. It uses precise terminology that indicates a security/permission operation rather than general IP management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the term 'whitelist' and by naming the specific resource (SIP account), but doesn't explicitly state when to use this versus alternatives like update_sip_account or when not to use it. The sibling tool get_allowed_ips suggests this is for adding to an existing list, but this isn't explicitly contrasted.
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 specifying the return format (CSV table), detailed column definitions, status meanings, and providing a concrete example. It doesn't mention rate limits, authentication needs, or pagination, but covers core behavioral aspects thoroughly.
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?
Well-structured with clear sections (Args, Returns, Example) and front-loaded purpose statement. Some redundancy exists (transaction_type explanations could be more concise), but overall information density is high with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with full schema coverage, no output schema, and no annotations, the description provides complete context: clear purpose, detailed parameter semantics, comprehensive return format specification with column definitions and status explanations, and a concrete example. Nothing essential appears missing for this data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value by providing detailed explanations of all transaction_type enum values and clarifying date format requirements, going well beyond what the schema provides. However, it doesn't add meaning for start_date/end_date beyond what's already in schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Load transaction history') and resource ('from DIDLogic'), distinguishing it from sibling tools like get_balance or get_call_history. It precisely defines what data is retrieved and from which system.
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 through the parameter explanations (e.g., transaction_type options, date ranges) but doesn't explicitly state when to use this tool versus alternatives like get_balance or get_call_history. No explicit when-not-to-use guidance or named alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and provides good behavioral context: it explains the return structure in detail, mentions pagination behavior, and discloses a specific error condition (403 for disabled API calls). It doesn't cover rate limits or authentication requirements, but adds substantial value beyond 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Example), but includes verbose JSON examples that could be summarized. The core information is front-loaded, but the example adds bulk without proportional value for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no annotations or output schema, the description provides excellent completeness: it explains all parameters, documents the full return structure with field meanings, includes pagination details, and mentions error conditions. No significant gaps remain for agent 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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining sms_enabled filters 'for DID with SMS functionality' and clarifying pagination defaults (page starts at 1), which goes beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('available DID in a city of a country'), specifying it's for purchasing. It distinguishes from siblings like list_countries or list_country_cities by focusing on available DIDs rather than geographic data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when searching for purchasable DIDs in a specific location, with optional SMS filtering. It doesn't explicitly state when not to use it or name alternatives like purchase_did, but the context is clear for its purpose.
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:

[![didlogic_mcp MCP server](https://glama.ai/mcp/servers/UserAd/didlogic_mcp/badges/card.svg)](https://glama.ai/mcp/servers/UserAd/didlogic_mcp)

Score Badge

Copy to your README.md:

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

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