What are MCP server commands?

MCP server commands are JSON-RPC methods on the wire, such as tools/list and tools/call. They are not shell commands and they are not the tool names the model picks. Tool names on DialMCP are place_call, get_call, end_call, and list_calls.

How does an MCP client call a tool?

The client first sends tools/list to learn names and input schemas, then tools/call with the tool name and arguments. Hosts such as Claude, Cursor, and Codex issue those JSON-RPC methods; you ask in natural language and approve the call.

How do DialMCP phone-call tools map onto tools/call?

DialMCP exposes four tools. place_call returns a call ID immediately; the agent then polls get_call. That asynchrony is in the tool results, not a second JSON-RPC method. See the DialMCP tool reference for the lifecycle.

Protocol reference

MCP server commands and tool calls.

Updated September 13, 2026

Search results for "MCP server commands" mix three different things: JSON-RPC methods on the wire, the tool names a model can pick, and shell commands that launch a local server. This page is the first of those. The DialMCP-specific tool names and call lifecycle live on the tool reference.

You rarely type these methods. Claude, Cursor, Codex, VS Code, and other hosts send tools/list and tools/call for you. After you connect DialMCP, ask the agent to place a call and approve the tool invocation. This page is for operators who need the wire shape, or who are building a client.

Commands vs tools vs prompts vs resources

Commands (JSON-RPC methods) are names like tools/list and tools/call. The client sends them. The 2026-07-28 tools spec is the current source.
Tools are the functions a model may invoke. Each has a name, a description, and an inputSchema. On DialMCP those names are place_call, get_call, end_call, and list_calls.
Prompts are user-triggered templates (prompts/list, prompts/get). DialMCP does not document prompts; phone calls go through tools. Longer explainer: MCP tools, prompts, and resources.
Resources are readable context (resources/list, resources/read). A tool result may include a resource link (for example a recording URI) without that URI appearing in resources/list.

Tool names are not methods. You never POST method: "place_call". You POST method: "tools/call" with params.name set to place_call.

List, then call

Servers that support tools declare a tools capability, optionally with listChanged. Clients discover the catalog with tools/list:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

The result is an array of tool definitions. Each name should be 1–128 characters, case-sensitive, and limited to letters, digits, underscore, hyphen, and dot. DialMCP's four names fit that rule.

To run a tool, the client sends tools/call:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "place_call",
    "arguments": {
      "destination": "+1…",
      "objective": "Confirm Tuesday 3pm with the clinic"
    }
  }
}

The argument keys above are illustrative of what place_call needs in prose (a US or Canadian destination and a stated objective). The live inputSchema is what tools/list returns after you connect; do not hard-code a private schema from this page. Product behavior for each tool is on the tool reference.

On Streamable HTTP, a 2026-07-28 request is one POST to the MCP endpoint (for DialMCP, https://mcp.dialmcp.com/mcp) with JSON-RPC in the body. The spec also requires protocol metadata on the request (MCP-Protocol-Version, Mcp-Method, and for tools/call a Mcp-Name header matching params.name). Hosts that already speak remote MCP set those. You do not add them to client config snippets.

What comes back

A completed tool result includes a content array (usually type: "text"). It may also include structuredContent when the tool advertised an outputSchema. The 2026-07-28 schema adds resultType: "complete" on a finished result.

Two different error channels exist, and mixing them is the usual client bug:

Protocol errors are JSON-RPC error objects (unknown tool, malformed request, server failure). Example: -32602 Unknown tool.
Tool execution errors are successful JSON-RPC responses with isError: true in the result (bad arguments, a rejected objective, a number the server will not dial). Hosts should feed these back to the model so it can retry.

A long-running tool may stream an SSE body on that same POST. That is still one tools/call, not a second method. DialMCP does not use that pattern for the phone call itself: place_call returns a call ID immediately, and the agent polls get_call. The call ID is an ordinary string in the tool result, then an argument on the next call. MCP has no protocol-level session handle for that; see "Stateful Tools" in the tools spec (checked September 13, 2026).

What this is not

Not a shell command. npx dialmcp-connector and claude mcp add start or register a client connection. They are not MCP methods. Snippets: install and client setup.
Not initialize on modern HTTP. Protocol revision 2026-07-28 dropped the handshake: each request carries version and client info in _meta. Revisions 2025-11-25 and earlier still open with initialize. Dual-era servers may answer both. Do not treat a missing initialize as a dead server if the client is on 2026-07-28.
Not Docker or config files. Packaging is deploy with Docker. Which file each host reads is configuration examples.

DialMCP mapping

After OAuth and SMS verification, a connected client should see four tools. Typical agent loop:

tools/call → place_call (destination + objective) → call ID.
tools/call → get_call until a terminal status.
Read the structured resolution, transcript, and recording link from that result.
tools/call → end_call only if the user wants to hang up early.
tools/call → list_calls to find an older ID.

Guardrails (disclosure, caller ID, hours, rate limits, blocked ranges) are enforced on the hosted server, not by extra JSON-RPC methods. Details: Safety and the tool reference. Connect first: install. Back to the docs hub.