CallMCP — Phone Call MCP Server

List SMS Messages

list_sms_messages

Read-onlyIdempotent

Read SMS and WhatsApp message evidence for accessible businesses (sms:read), including provider message ID, carrier status, delivery/failure timestamps and failure code. Filter by business_id, conversation or direction, and search by phone number (either side), words in the message, and date window. Provider acceptance is not delivery; delivered_at and carrier status record delivery. Uses offset pagination.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_sms_messages"
  }
}

Input Schema

Name	Required	Description
`after`	No	Only items at or after this ISO-8601 date or time (optional).
`limit`	No	Max results to return (default 50, max 100)
`phone`	No	Only this caller: any phone format; matches on the last 10 digits (optional).
`query`	No	Words to find in the message text (optional).
`before`	No	Only items before this ISO-8601 date or time (optional).
`offset`	No	Zero-based pagination offset (default 0)
`direction`	No	Filter by direction: inbound or outbound (optional)
`business_id`	No	Narrow to one accessible business (optional).
`conversation_id`	No	Filter by conversation ID (optional)

Output Schema

Name	Required	Description
`count`	No
`error`	No	Present when success is false
`limit`	No
`offset`	No
`filters`	No
`success`	Yes	Whether the tool completed successfully
`has_more`	No
`messages`	No
`next_offset`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: the required sms:read scope, restriction to 'accessible businesses', offset-based pagination, and the important semantic caveat that 'Provider acceptance is not delivery' — pointing the agent at delivered_at and carrier status as the authoritative delivery signal. It omits rate limits and the effective max result set, keeping it below a 5.

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?

Three dense sentences, front-loaded with purpose, then filters, then the delivery-status caveat and pagination. Every sentence carries information, though the middle sentence stacks filters in a list-like run that is slightly denser than needed.

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?

With an output schema present, return values need not be spelled out, and annotations plus full schema coverage handle safety and arguments. The description fills the remaining gaps an agent needs — permission scope, tenancy scoping, pagination style, and the acceptance-vs-delivery distinction — so it is complete for a filter-and-list tool.

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 coverage is 100%, so the schema already documents all nine parameters; baseline is 3. The description adds modest but real meaning beyond it: that phone search applies to 'either side' of the conversation (resolving the schema's narrower 'Only this caller' wording) and that after/before form a combined 'date window'. It adds nothing about limit/offset interaction or how query tokenizes words.

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 opens with a specific verb and resource ('Read SMS and WhatsApp message evidence') and immediately enumerates the payload fields returned (provider message ID, carrier status, delivery/failure timestamps, failure code). This makes it unambiguously distinct from the write-side sibling send_sms and from list_conversations, which returns conversations rather than messages.

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?

Usage is implied rather than stated: the filter inventory ('Filter by business_id, conversation or direction') tells an agent what it can narrow by, but there is no explicit when-to-use vs when-not guidance and no routing to list_conversations for discovering the conversation_id this tool accepts. The permission hint (sms:read) and the 'accessible businesses' scoping are helpful context but are not selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All CallMCP — Phone Call MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.