Skip to main content
Glama
UserAd

didlogic_mcp

list_country_cities

Retrieve a list of cities in a specific country where DIDs are available for purchase, including SMS-enabled options. Returns JSON with city IDs, names, area codes, and available DID counts.

Instructions

List of Cities with available DID for purchase in a country

Args: country_id: ID of country for search sms_enabled: search for DID with SMS functionality

Returns a JSON object with available cities for purchase DIDs. Returned cities list have following fields: id: ID of city name: Name of city in DIDLogic area_code: Area code within country count: count of available DIDs for purchasing

403 error indicates disabled API calls for purchase.

Example:

{
    "cities": [
        {
            "id": 118557,
            "name": "Ottawa-Hull, ON",
            "area_code": "613800",
            "count": 81
        }
    ]
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
country_idYesCountry ID
sms_enabledNoFilter for sms enabled numbers

Implementation Reference

  • The handler function for the 'list_country_cities' MCP tool. Decorated with @mcp.tool(), it takes country_id and optional sms_enabled parameters (defined with Field for schema), calls the DIDLogic API to list cities with available DIDs, and returns the JSON response as string.
    async def list_country_cities(
        ctx: Context,
        country_id: int = Field(description="Country ID"),
        sms_enabled: Optional[bool] = Field(
            description="Filter for sms enabled numbers", default=None
        )
    ) -> str:
        """
            List of Cities with available DID for purchase in a country
    
            Args:
                country_id: ID of country for search
                sms_enabled: search for DID with SMS functionality
    
            Returns a JSON object with available cities for purchase DIDs.
            Returned cities list have following fields:
                id: ID of city
                name: Name of city in DIDLogic
                area_code: Area code within country
                count: count of available DIDs for purchasing
    
            403 error indicates disabled API calls for purchase.
    
            Example:
            ```
            {
                "cities": [
                    {
                        "id": 118557,
                        "name": "Ottawa-Hull, ON",
                        "area_code": "613800",
                        "count": 81
                    }
                ]
            }
            ```
        """
        params = {}
        if sms_enabled is not None:
            params["sms_enabled"] = int(sms_enabled)
    
        response = await base.call_didlogic_api(
            ctx,
            "GET",
            f"/v2/buy/countries/{country_id}/cities",
            params=params
        )
        return response.text
  • Input schema defined using Pydantic Field in the function signature: country_id (int, required), sms_enabled (Optional[bool]).
    ctx: Context,
    country_id: int = Field(description="Country ID"),
    sms_enabled: Optional[bool] = Field(
        description="Filter for sms enabled numbers", default=None
    )
  • Tool registration via @mcp.tool() decorator above the handler function.
    @mcp.tool()
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.

Install Server

Other Tools

Related Tools

Latest Blog Posts

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