The MCP request path

Client
  ↓ tools/list
Tool catalog
  ↓ tools/call
Schema validation
  ↓
Handler
  ↓
Success or visible error

MCP standardizes discovery and calls. It does not approve the server or make its
result correct.

Five boundaries to review

Start with stdio and synthetic data. Keep the first review small.

Start with one narrow capability

{
  "name": "get_weather",
  "description": "Return deterministic synthetic current weather for one city.",
  "inputSchema": {
    "type": "object",
    "required": ["city"],
    "additionalProperties": false
  }
}

Clients use the tool name, description, and schema as part of the interface.

Start with one tool because every exposed capability adds risk and maintenance.

Trace the good request

{
  "name": "get_weather",
  "arguments": {
    "city": "Oslo"
  }
}

{
  "city": "Oslo",
  "temperature": 30,
  "unit": "celsius",
  "conditions": "rain"
}

Deterministic synthetic output makes exact tests possible.

Trace the bad request

{
  "name": "get_weather",
  "arguments": {
    "city": "   "
  }
}

{
  "error": "city must be a non-empty string"
}

The MCP result sets isError: true. An invalid request must not look like an empty
success response.

Schema and handler checks work together

Do not assume every caller reaches the handler through the same client-side check.

What each check shows

Keep the deterministic tests even when the client integration works.

Lab handoff

Apply the same contract to three tools. Check discovery, valid input, invalid input,
and visible errors through tests and the MCP Inspector.

Submit a three-tool server with recorded requests, responses, and errors.