Skip to main content
Glama
UserAd

didlogic_mcp

add_allowed_ip

Whitelist an IP address for a SIP account to enable secure communication. Input the SIP account name and IP address to return a JSON list of all allowed IPs for the account.

Instructions

Whitelist an IP to a SIP account

Args: sipaccount_name: Name of SIP account ip: IP address to allow

Returns a JSON object with all whitelisted IP addresses for account Example output: { "allowed_ips": [ "88.99.12.33", "99.33.55.11" ] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipYesIP address to allow
sipaccount_nameYesName of sip account

Implementation Reference

  • The handler function that implements the 'add_allowed_ip' tool logic. It takes sipaccount_name and ip parameters (with Pydantic validation), sends a POST request to the Didlogic API via base.call_didlogic_api, and returns the response.
    async def add_allowed_ip(ctx: Context,
                             sipaccount_name: str | int = Field(
                                 description="Name of sip account"
                             ),
                             ip: str = Field(
                                 description="IP address to allow")
                             ) -> str:
        """
            Whitelist an IP to a SIP account
    
            Args:
                sipaccount_name: Name of SIP account
                ip: IP address to allow
    
            Returns a JSON object with all whitelisted IP addresses for account
            Example output: { "allowed_ips": [ "88.99.12.33", "99.33.55.11" ] }
    
        """
        data = {"ip": ip}
        response = await base.call_didlogic_api(
            ctx,
            "POST",
            f"/v1/sipaccounts/{sipaccount_name}/allowed_ips",
            data=data
        )
        return response.text
  • Registration block in the main server file where tools.allowed_ips.register_tools(mcp) is called to register the add_allowed_ip tool (among others) to the FastMCP server.
    tools.balance.register_tools(mcp)
    tools.sip_accounts.register_tools(mcp)
    tools.allowed_ips.register_tools(mcp)
    tools.purchases.register_tools(mcp)
    tools.purchase.register_tools(mcp)
    tools.calls.register_tools(mcp)
    tools.transactions.register_tools(mcp)
  • The register_tools function decorated with @mcp.tool() decorators for add_allowed_ip and related tools, which performs the actual tool registration when called.
    def register_tools(mcp: FastMCP):
        @mcp.tool()
        async def get_allowed_ips(
                ctx: Context,
                sipaccount_name: str | int = Field()
        ) -> str:
            """
                Get list of whitelisted IPs for a SIP account
    
                Args:
                    sipaccount_name: Name of SIP account
    
                Returns a JSON object with array of whitelisted IP for SIP Account
                Example output: { "allowed_ips": [ "88.99.12.33" ] }
            """
            response = await base.call_didlogic_api(
                ctx, "GET",
                f"/v1/sipaccounts/{sipaccount_name}/allowed_ips"
            )
            return response.text
    
        @mcp.tool()
        async def add_allowed_ip(ctx: Context,
                                 sipaccount_name: str | int = Field(
                                     description="Name of sip account"
                                 ),
                                 ip: str = Field(
                                     description="IP address to allow")
                                 ) -> str:
            """
                Whitelist an IP to a SIP account
    
                Args:
                    sipaccount_name: Name of SIP account
                    ip: IP address to allow
    
                Returns a JSON object with all whitelisted IP addresses for account
                Example output: { "allowed_ips": [ "88.99.12.33", "99.33.55.11" ] }
    
            """
            data = {"ip": ip}
            response = await base.call_didlogic_api(
                ctx,
                "POST",
                f"/v1/sipaccounts/{sipaccount_name}/allowed_ips",
                data=data
            )
            return response.text
    
        @mcp.tool()
        async def delete_allowed_ip(
                ctx: Context,
                sipaccount_name: str | int = Field(
                    description="Name of sip account"
                ),
                ip: str = Field(description="IP address to remove from whitelist")
        ) -> str:
            """
                Delete an whitelisted IP from a SIP account
    
                Args:
                    sipaccount_name: Name of SIP account
                    ip: IP address to remove from whitelist
    
                Returns "IP removed successfully" when IP removed from whitelisted
            """
            params = {"ip": ip}
            await base.call_didlogic_api(
                ctx,
                "DELETE",
                f"/v1/sipaccounts/{sipaccount_name}/allowed_ips",
                params=params
            )
            return "IP removed successfully"
  • Uses the helper base.call_didlogic_api to make the API call for adding the IP.
    data = {"ip": ip}
    response = await base.call_didlogic_api(
        ctx,
        "POST",
        f"/v1/sipaccounts/{sipaccount_name}/allowed_ips",
        data=data
    )
    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. 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.

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