Distinguish finding a tool from searching content

Understand the approach

Tool discovery asks which operation can answer a request. Content search uses a chosen operation to locate documents, tickets or records. Keeping these separate prevents a common confusion: discovering a documentation search tool does not mean you have searched the documentation yet. Reading a result is another step. A reliable trace can therefore contain discovery, search and read, with a distinct observation at each stage.

Some agent hosts expose deferred tool discovery so they do not present every tool schema at once. OpenAI's API Tool search guide documents API-specific setup, including deferred loading. That is not a Codex configuration recipe. The current local Codex guide provides /mcp for inspecting configured capabilities and tool allow/deny controls, but does not establish the source course's Claude search switches as Codex controls. Do not paste an API tools array or a Claude environment variable into config.toml and assume it enables the same mechanism.

Learn the distinction by working backward from a narrow question. To verify a setting, you need an operation that searches official documentation and another that reads the matching page. Ask Codex to identify the operations it actually has, rather than listing attractive tool names from memory. If your environment presents a complete catalogue instead of a search step, record that honestly. The goal is correct selection and retrieval; a visible discovery call is not mandatory in every client and is not a measure of answer quality.

Inspect server.cjs’s actual inputSchema: list_tasks accepts optional string query and searches titles; get_task requires an exact string id; read_task_snapshot takes no arguments. A no-such-title search yields isError:false and total:0. An unknown ID yields isError:true; the absent erase_all tool returns protocol error -32602. These are distinct observable contracts. The transcript contains tools/list followed by content calls, not proof of deferred model-side schema loading. If native Codex presents a full catalog instead, demonstrate correct selection, retrieval and reconciliation rather than inventing a discovery API or a token-saving figure.

Practice and acceptance

Finding an operation, invoking it and interpreting source content are separate observable steps.

Try it step by step

1. Read the linked lab guide, inputs and expected outputs before running the exercise.
2. Write a specific lookup goal and the operation characteristics required, such as read-only documentation search with page retrieval.
3. Inspect the current client or ask Codex to identify matching available capabilities. In an interactive CLI, /mcp can help inspect connected tools.
4. If the host exposes deferred discovery, use it to locate the operation. Otherwise select from the available catalogue and note that no separate search was needed.
5. Run the content query, read the supporting result and return an answer with a source URL. Keep discovery activity separate from evidence retrieval.
6. Review the trace for unnecessary catalogue expansion or repeated searches. Compare useful results and observed effort without inventing token savings.

A useful starting example

Illustration · adapt before use.

{"jsonrpc":"2.0","id":10,"method":"tools/list","params":{}}
{"jsonrpc":"2.0","id":11,"method":"tools/call","params":{"name":"list_tasks","arguments":{"query":"README"}}}
{"jsonrpc":"2.0","id":12,"method":"tools/call","params":{"name":"get_task","arguments":{"id":"T-102"}}}

Check your result

• The report distinguishes discovering an operation from searching service content.
• Only actual available capabilities are named as used.
• API-specific tool_search setup and Claude-specific switches are not presented as verified Codex settings.
• Local harness behavior and isolated native server discovery are distinguished from unrun app UI setup or model-selected tool calls.

Common mistakes

• Confusing /mcp server inspection with having searched a service's documents.
• Claiming automatic performance improvements without observing the task, latency or usage in the relevant environment.