Skip to main content
Glama
UserAd

didlogic_mcp

list_countries

Retrieve available countries for purchasing virtual phone numbers (DIDs) with optional SMS functionality. Returns JSON data including country ID, name, ISO code, and province/state availability.

Instructions

List available countries with DID for purchase on DIDLogic

Args: sms_enabled: search for DID with SMS functionality

Returns a JSON object with available countries for purchase. Returned countries list have following fields: id: ID of country name: Name of country in DIDLogic short_name: ISO code of country has_provinces_or_states: do country have provinces or states which can be queried by list_country_regions tool.

403 error indicates disabled API calls for purchase.

Example:

    {
        "countries": [
            {
                "id": 8669,
                "name": "Argentina",
                "short_name": "AR",
                "has_provinces_or_states": false
            }
        ]
    }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sms_enabledNoFilter for sms enabled numbers

Implementation Reference

  • The handler function that implements the logic for the 'list_countries' tool. It accepts an optional sms_enabled filter, constructs API parameters, calls the DIDLogic /v2/buy/countries endpoint via base.call_didlogic_api, and returns the response text.
    @mcp.tool()
    async def list_countries(
            ctx: Context,
            sms_enabled: Optional[bool] = Field(
                description="Filter for sms enabled numbers", default=None
            )
    ) -> str:
        """
            List available countries with DID for purchase on DIDLogic
    
            Args:
                sms_enabled: search for DID with SMS functionality
    
            Returns a JSON object with available countries for purchase.
            Returned countries list have following fields:
                id: ID of country
                name: Name of country in DIDLogic
                short_name: ISO code of country
                has_provinces_or_states: do country have provinces or states
                    which can be queried by list_country_regions tool.
    
            403 error indicates disabled API calls for purchase.
    
            Example:
            ```
                {
                    "countries": [
                        {
                            "id": 8669,
                            "name": "Argentina",
                            "short_name": "AR",
                            "has_provinces_or_states": false
                        }
                    ]
                }
            ```
    
    
        """
        params = {}
        if sms_enabled is not None:
            params["sms_enabled"] = int(sms_enabled)
        response = await base.call_didlogic_api(
            ctx,
            "GET",
            "/v2/buy/countries",
            params=params
        )
        return response.text
  • Top-level registration of the purchase tools module, which includes the list_countries tool, by invoking its register_tools function on the MCP server instance.
    tools.purchase.register_tools(mcp)
  • Pydantic schema definition for the input parameter 'sms_enabled' used in the list_countries tool.
    sms_enabled: Optional[bool] = Field(
        description="Filter for sms enabled numbers", default=None
    )
  • The supporting helper function call_didlogic_api used by the list_countries handler to perform the actual HTTP request to the DIDLogic API, handling authentication based on the transport mode.
    async def call_didlogic_api(
        ctx: Context,
        method: str,
        path: str,
        params: Optional[Dict] = None,
        data: Optional[Dict] = None,
        json: Optional[Dict] = None
    ) -> httpx.Response:
        """
        Make a call to the Didlogic API.
    
        In HTTP/SSE mode, extracts Bearer token from request context and adds it
        to the Authorization header for each API call.
        In STDIO mode, uses the API key already configured in the client headers.
        """
        client = ctx.request_context.lifespan_context.client
    
        # In HTTP/SSE mode, get API key from request.state (set by middleware)
        extra_headers = {}
    
        # Check if we have a request object (indicates HTTP/SSE mode)
        request = getattr(ctx.request_context, "request", None)
    
        if request and hasattr(request, 'state') and hasattr(request.state, 'didlogic_api_key'):
            # HTTP/SSE mode: extract API key from request state
            api_key = request.state.didlogic_api_key
            if api_key:
                extra_headers["Authorization"] = f"Bearer {api_key}"
                logger.debug(f"Using API key from request state: {api_key[:8]}...")
            else:
                logger.warning("No API key found in request state")
        else:
            # STDIO mode: API key already in client headers from lifespan
            logger.debug("Using API key from client headers (STDIO mode)")
    
        response = await client.request(
            method=method,
            url=path,
            params=params,
            data=data,
            json=json,
            headers=extra_headers
        )
        response.raise_for_status()
        return response
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.

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