Explore tools Verify the endpoint, initialize the protocol, inspect tool schemas and run one bounded task before handing a new MCP server to your assistant.
Registry metadata is discovery evidence. A successful tool result proves only the tested path.
Inspect the server owner, endpoint or package, transport and permissions. A registry listing describes a service; it does not certify runtime safety. For local packages, review the command and environment access before starting a process on your machine.
The MCP lifecycle begins with initialize. Check the server response for a supported protocol version and negotiated capabilities, then send notifications/initialized. For HTTP, use the negotiated version header on subsequent requests. Use a client that handles its transport and session details rather than guessing them.
Request tools/list and read the input schema for the task you intend to run. A descriptive tool name does not explain all side effects. Check required fields, limits and external services. Do not approve filesystem writes, messages or purchases merely to establish connectivity.
Choose an authorized read-only action with a known input and an independently inspectable output. Submit tools/call using the actual returned schema. Compare the result to the expected resource. HTTP success alone does not establish that the tool completed its job.
A JSON-RPC error, a tool execution error and an empty successful result mean different things. Record the layer, exact code and a redacted reproduction. Check authentication, schema and transport before changing tools. A payment challenge requires a separate approved payment test.
Save the tested server version, endpoint, tool, input shape and observed outcome without tokens or private content. Repeat after meaningful configuration changes. A passed sample is useful evidence for that route and moment, not a guarantee for every tool or future run.
Reviewed 2026-09-14