Skip to main content
Glama
UserAd

didlogic_mcp

delete_sip_account

Remove a SIP account from the didlogic_mcp server by specifying its name. Returns confirmation upon successful deletion.

Instructions

Delete a SIP account

Args: name: SIP account name

Returns a SIP Account deleted message on success

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName of SIP account

Implementation Reference

  • The handler function decorated with @mcp.tool() that implements the logic for deleting a SIP account by issuing a DELETE request to the DidLogic API endpoint /v1/sipaccounts/{name} using the base helper, and returns a success message. Includes inline schema via Pydantic Field.
    @mcp.tool()
    async def delete_sip_account(
            ctx: Context, name: str | int = Field(
            description="Name of SIP account")) -> str:
        """
            Delete a SIP account
    
            Args:
                name: SIP account name
    
            Returns a `SIP Account deleted` message on success
        """
    
        await base.call_didlogic_api(
            ctx, "DELETE", f"/v1/sipaccounts/{name}"
        )
    
        return "SIP Account deleted"
  • Registers the sip_accounts tools (including delete_sip_account) with the FastMCP server instance by calling the register_tools function defined in the module.
    tools.sip_accounts.register_tools(mcp)
  • Shared helper function that performs authenticated HTTP requests to the DidLogic API, handling both STDIO and HTTP/SSE transport modes by extracting or using the API key appropriately. Used by delete_sip_account to execute the DELETE request.
    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
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.

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