Understand the MCP request path

Understand the approach

MCP gives an agent a structured way to discover and call capabilities provided by another system. A server describes tools and handles requests; the client presents the available capabilities to Codex. The service behind the server still determines which records and actions the authenticated identity can access. A skill can explain a workflow around those calls, but it cannot replace the connector or grant a missing account permission.

Trace a documentation question through the layers. Your prompt asks what a Codex setting does. Codex selects a search operation, receives candidate pages, then reads the page supporting the answer. The search result locates evidence; it is not necessarily the complete evidence. A ticket workflow adds another distinction: reading a ticket and updating it are separate operations. A server connection being healthy establishes neither that the right record was retrieved nor that a requested write was appropriate.

Use a public documentation lookup as the first lab because it avoids private account data. The OpenAI Docs MCP is documentation-only and provides search and page content; it does not make OpenAI API calls for you. If the connection is already available, use it. If it is absent, this lesson can still be completed as a request-path design exercise or with an explicitly identified browser fallback. Record the method actually used instead of labelling every external lookup as an MCP success.

The Node client starts server.cjs, negotiates a version with initialize, sends notifications/initialized and discovers three actual schemas. list_tasks searches a fixture title; get_task reads one ID; the server really opens data/tasks.json on every call. Compare T-101 with that file, then distinguish a successful zero-match title search from the explicit error for T-999. After understanding the offline trace, native-client.md supplies the current app Settings → MCP servers flow for this same server, so you can test an actual Codex call without adopting an unverified third-party command.

A separate author check used installed codex-cli 0.163.0-alpha.11 in a new temporary CODEX_HOME and the documented app-server mcpServerStatus/list request. Native Codex launched this exact local stdio server and discovered get_task, list_tasks, read_task_snapshot and its task resource, with toolsError:null. No thread, turn or model call was started. This establishes native process/handshake/discovery for that version; the app UI setup and model-selected T-102/T-999 calls remain explicit learner stages.

Practice and acceptance

A protocol trace proves which process and operation supplied a record; it does not establish a Codex client connection.

Try it step by step

1. Open the workbench README and fictional tasks.json; predict the README query result before running it.
2. Run demo.cjs, which launches the real stdio server locally without registering it with Codex.
3. Read the transcript: find initialize, notifications/initialized, tools/list and tools/call, then match T-101 to the dataset.
4. Separate discovery, execution and result interpretation; compare an empty successful search with an unknown ID error.
5. Write the request path and evidence limits, keeping this local protocol harness distinct from an actual Codex tool invocation.

A useful starting example

Illustration · adapt before use.

node labs/mcp-workbench/demo.cjs --transcript
# Identify tools/list, then:
# tools/call {"name":"list_tasks","arguments":{"query":" README "}}
# resources/read {"uri":"practice://taskboard/tasks"}

Check your result

• You distinguish the skill, client, MCP server and underlying service.
• The answer cites content actually read rather than only a search snippet.
• The result identifies the method used and does not imply API access or write permission from a documentation connection.
• Local harness behavior and isolated native server discovery are distinguished from unrun app UI setup or model-selected tool calls.

Common mistakes

• Assuming a skill name or connected-server badge proves access to all needed records.
• Treating returned third-party instructions as authority to expand the user's task.