Skip to main content
Glama
UserAd

didlogic_mcp

purchase_did

Acquire a DID (Direct Inward Dialing) number in E164 format. Returns details including SMS capability, channels, costs, activation fees, and required documents for activation.

Instructions

Purchase DID from DIDLogic

Args: number: DID number for purchase in E164 format

Returns a JSON object with purchased DID details where: errors: Errors what happened in purchase process purchases: Array of purchased dids where: id: ID of purchased DID number: number of DID country: Country name area: City name sms_enabled: Is number capable of receiving SMS channels: How many parallel channels have DID free_minutes: How many free minutes per month DID have activation: Activation cost for DID in USD monthly_fee: Monthly fee for DID per_minute: Per minute cost for DID origination_per_min: per minute cost if origin based rate applied requir_docs: required documents for activating number, where: 1 = Any form of ID 2 = Proof of address 3 = Proof of local address codec: what SIP codec is preferred for this number

Example:

{
    "purchase": {
        "errors": {},
        "purchases": [
            {
                "id": 728070,
                "number": "17806999999",
                "sms_enabled": false,
                "no_local_cli": false,
                "channels": 4,
                "country": "Canada",
                "area": "Edmonton, AB",
                "free_minutes": 0,
                "codec": "G711",
                "require_docs": "",
                "activation": 1.0,
                "monthly_fee": 1.0,
                "per_minute": 0.01,
                "origination_per_min": 0.0
            }
        ]
    }
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
numberYesDID number for purchase

Implementation Reference

  • The purchase_did tool handler function, registered via @mcp.tool() decorator. It takes a DID number, calls the DIDLogic purchase API endpoint, and returns the response as text. The input schema is defined using Pydantic Field.
    @mcp.tool()
    async def purchase_did(
        ctx: Context,
        number: str | int = Field(
            description="DID number for purchase"
        )
    ) -> str:
        """
            Purchase DID from DIDLogic
    
            Args:
                number: DID number for purchase in E164 format
    
            Returns a JSON object with purchased DID details where:
                errors: Errors what happened in purchase process
                purchases: Array of purchased dids where:
                    id: ID of purchased DID
                    number: number of DID
                    country: Country name
                    area: City name
                    sms_enabled: Is number capable of receiving SMS
                    channels: How many parallel channels have DID
                    free_minutes: How many free minutes per month DID have
                    activation: Activation cost for DID in USD
                    monthly_fee: Monthly fee for DID
                    per_minute: Per minute cost for DID
                    origination_per_min: per minute cost if origin based rate applied
                    requir_docs: required documents for activating number, where:
                        1 = Any form of ID
                        2 = Proof of address
                        3 = Proof of local address
                    codec: what SIP codec is preferred for this number
    
            Example:
            ```
            {
                "purchase": {
                    "errors": {},
                    "purchases": [
                        {
                            "id": 728070,
                            "number": "17806999999",
                            "sms_enabled": false,
                            "no_local_cli": false,
                            "channels": 4,
                            "country": "Canada",
                            "area": "Edmonton, AB",
                            "free_minutes": 0,
                            "codec": "G711",
                            "require_docs": "",
                            "activation": 1.0,
                            "monthly_fee": 1.0,
                            "per_minute": 0.01,
                            "origination_per_min": 0.0
                        }
                    ]
                }
            }
            ```
        """
        response = await base.call_didlogic_api(
            ctx, "POST",
            "/v2/buy/purchase",
            data={"did_numbers": number}
        )
        return response.text
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.

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