Skip to main content
Glama
OpenSIPS

OpenSIPS MCP Server

Official
by OpenSIPS

homer_search_calls

Search SIP call logs captured by Homer using filters for caller, callee, call ID, and time range to locate specific calls.

Instructions

Search SIP calls captured by Homer/SIPCAPTURE.

Parameters

caller: Filter by calling party (From user). callee: Filter by called party (To user). call_id: Filter by SIP Call-ID. time_from: Start of time range (ISO-8601 string). time_to: End of time range (ISO-8601 string).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
callerNo
calleeNo
call_idNo
time_fromNo
time_toNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The MCP tool handler function for 'homer_search_calls'. Decorated with @mcp.tool() and @require_permission('mi.read'). Accepts caller, callee, call_id, time_from, time_to as optional parameters, then delegates to HomerClient.search_calls().
    @mcp.tool()
    @require_permission("mi.read")
    async def homer_search_calls(
        ctx: Context,
        caller: str | None = None,
        callee: str | None = None,
        call_id: str | None = None,
        time_from: str | None = None,
        time_to: str | None = None,
    ) -> dict[str, Any]:
        """Search SIP calls captured by Homer/SIPCAPTURE.
    
        Parameters
        ----------
        caller:
            Filter by calling party (From user).
        callee:
            Filter by called party (To user).
        call_id:
            Filter by SIP Call-ID.
        time_from:
            Start of time range (ISO-8601 string).
        time_to:
            End of time range (ISO-8601 string).
        """
        app = ctx.request_context.lifespan_context
        return await HomerClient.search_calls(
            app.http_client,
            _homer_url(app),
            caller=caller,
            callee=callee,
            call_id=call_id,
            time_from=time_from,
            time_to=time_to,
        )
  • The HomerClient.search_calls() static method that builds the JSON body and POSTs to Homer's /api/v3/call/transaction endpoint to search captured SIP calls.
    async def search_calls(
        http_client: httpx.AsyncClient,
        homer_url: str,
        *,
        caller: str | None = None,
        callee: str | None = None,
        call_id: str | None = None,
        time_from: str | None = None,
        time_to: str | None = None,
    ) -> dict[str, Any]:
        """Search captured SIP calls in Homer.
    
        Parameters
        ----------
        http_client:
            Shared httpx async client.
        homer_url:
            Homer base URL (e.g. ``http://homer:9080``).
        caller:
            Filter by calling party (From user).
        callee:
            Filter by called party (To user).
        call_id:
            Filter by SIP Call-ID.
        time_from:
            Start of time range (ISO-8601 or epoch).
        time_to:
            End of time range (ISO-8601 or epoch).
        """
        base = homer_url.rstrip("/")
        search_body: dict[str, Any] = {
            "param": {
                "transaction": {"call": True},
                "limit": 200,
                "search": {},
            },
        }
    
        search_params = search_body["param"]["search"]
        if caller:
            search_params["from_user"] = caller
        if callee:
            search_params["to_user"] = callee
        if call_id:
            search_params["callid"] = call_id
    
        if time_from:
            search_body["timestamp"] = search_body.get("timestamp", {})
            search_body["timestamp"]["from"] = time_from
        if time_to:
            search_body["timestamp"] = search_body.get("timestamp", {})
            search_body["timestamp"]["to"] = time_to
    
        try:
            resp = await http_client.post(f"{base}{_SEARCH_PATH}", json=search_body)
            resp.raise_for_status()
            return resp.json()  # type: ignore[no-any-return]
        except httpx.HTTPStatusError as exc:
            logger.warning("Homer search failed: %s", exc)
            return {"error": str(exc), "status_code": exc.response.status_code}
        except httpx.HTTPError as exc:
            logger.warning("Homer search connection error: %s", exc)
            return {"error": str(exc)}
  • Tool documentation resource entry for 'homer_search_calls' describing parameters, permission, and example usage.
    _TOOL_DOCS: dict[str, dict[str, str]] = {
        "homer_search_calls": {
            "description": "Search SIP calls captured by Homer/SIPCAPTURE",
            "parameters": "caller, callee, call_id, time_from, time_to",
            "permission": "mi.read",
            "example": 'homer_search_calls(caller="alice", time_from="2026-01-01T00:00:00Z")',
        },
  • Registration of 'homer_search_calls' in the available_tools listing under the 'homer' category for the ecosystem_overview tool.
    "homer": ["homer_search_calls", "homer_get_call_flow", "homer_stats"],
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits, but it does not mention whether the operation is read-only, destructive, or requires authentication. It also omits details about pagination, limits, or output format, leaving significant gaps.

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 front-loads the purpose but dedicates a long parameter list. It is adequately structured but could be more concise by omitting obvious parameter explanations or integrating them into a shorter form.

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?

Given 5 parameters and an existing output schema, the description does not explain the output structure or common usage patterns. It provides only basic filter descriptions, leaving the agent uninformed about expected results or limitations.

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 0%, so the description must compensate. It provides a one-line explanation for each of the 5 parameters (e.g., 'caller: Filter by calling party (From user)'). While this adds some meaning, it largely restates what parameter names imply, and lacks format constraints or examples.

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 searches SIP calls with filters for caller, callee, call_id, and time range. However, it does not differentiate from similar tools like homer_search_calls_v7 or homer_correlate_callid, which is a missed opportunity.

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?

No guidance is provided on when to use this tool versus alternatives. It lacks any conditional or exclusionary language, leaving the agent to infer usage from the tool name alone.

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

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/OpenSIPS/opensips-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server