Skip to main content
Glama

lookup_rate

Read-onlyIdempotent

Check per-minute calling rates for phone numbers to calculate costs before dialing.

Instructions

Look up the calling rate for a specific phone number. Returns the per-minute cost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
phone_numberYesPhone number in E.164 format (e.g. +442071234567)

Implementation Reference

  • The handler function for lookup_rate tool - an async arrow function that calls client.post() to look up rates for a phone number via the /rates/lookup-number endpoint. Wrapped by callTool for error handling.
    async (params) => callTool(() => client.post("/rates/lookup-number", { phone_number: params.phone_number }))
  • The input schema definition for lookup_rate tool using Zod validation. Defines phone_number as a required string in E.164 format, along with tool annotations.
    {
      description: "Look up the calling rate for a specific phone number. Returns the per-minute cost.",
      inputSchema: {
        phone_number: z.string().describe("Phone number in E.164 format (e.g. +442071234567)"),
      },
      annotations: { readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true },
    },
  • Registration of the lookup_rate tool with the MCP server. Associates the tool name with its schema definition and handler function.
    server.registerTool(
      "lookup_rate",
      {
        description: "Look up the calling rate for a specific phone number. Returns the per-minute cost.",
        inputSchema: {
          phone_number: z.string().describe("Phone number in E.164 format (e.g. +442071234567)"),
        },
        annotations: { readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true },
      },
      async (params) => callTool(() => client.post("/rates/lookup-number", { phone_number: params.phone_number }))
    );
  • Helper function that wraps tool execution with try/catch error handling. Converts API errors to tool error responses and successful results to tool result responses.
    async function callTool<T>(fn: () => Promise<T>) {
      try {
        return toolResult(await fn());
      } catch (err) {
        const apiErr = err as ApiError;
        return toolError(`API error (${apiErr.status}): ${apiErr.message}`);
      }
    }
  • The BubblyPhoneClient.post method used by the lookup_rate handler to make POST requests to the API. Handles JSON serialization and content-type headers.
    async post<T = unknown>(path: string, body?: Record<string, unknown>): Promise<T> {
      return this.request<T>(`${this.baseUrl}${path}`, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: body ? JSON.stringify(body) : undefined,
      });
    }
Behavior4/5

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

Annotations cover safety (readOnlyHint, destructiveHint) and idempotency. The description adds valuable behavioral context by specifying the tool 'Returns the per-minute cost,' explaining what the rate represents without contradicting the read-only annotations.

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?

Two sentences with zero waste: the first states the action and target, the second clarifies the return value. Perfectly front-loaded with no filler text.

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 simple read-only lookup with one parameter and no output schema, the description is nearly complete. It covers the lookup purpose and return value semantics (per-minute cost), though specifying the currency format would make it fully complete.

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?

With 100% schema description coverage (E.164 format with example), the schema fully documents the parameter. The description references 'phone number' but does not add semantic details beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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 uses a specific verb ('Look up') with a specific resource ('calling rate for a specific phone number'), clearly distinguishing it from the sibling tool 'get_country_rates' which operates at the country level rather than on specific phone numbers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description implies usage by specifying 'specific phone number,' it lacks explicit guidance on when to use this tool versus the sibling 'get_country_rates' (e.g., 'Use this for individual number pricing; use get_country_rates for country-wide tariffs').

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

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