Tool authoring MCP
Developer MCP exposes Method Tool-development workflows to MCP clients. Use it when you want Claude Code, Codex, MCP Inspector, or another MCP client to build, validate, draft, and publish Method Tools against a Method instance.
For the Tool definition structure and worked examples, see the Tool authoring reference. For the UI walkthrough, see Operator-defined Tools.
Prerequisites
You need:
- Access to a deployed Method instance with Developer MCP enabled
- The instance’s Developer MCP endpoint
- A Method account with permission to manage Tools in that instance
The hosted endpoint is usually:
Configure Codex
Codex configures MCP servers in ~/.codex/config.toml. Add a developer entry for your instance:
Restart Codex after editing ~/.codex/config.toml, or start a new task so the client reloads MCP config. On first use, Codex should open a browser OAuth flow.
Configure Claude Code
From the repository root, register the hosted server with Claude Code. For a team-shared project config, use project scope:
That writes or updates .mcp.json in the repo:
For a private, per-user Claude Code config instead, omit --scope project:
Run Claude Code from the repo root:
Claude Code may ask you to approve the project-scoped MCP server. Then run /mcp and follow the browser login flow if the server shows as needing authentication. The instance’s OAuth client should allow loopback redirect URLs such as http://localhost:*/* and http://127.0.0.1:*/*, which covers Claude Code and Codex callback path variants.
Configure MCP Inspector
MCP Inspector is useful for verifying that the hosted server is reachable and that Tool schemas are available before wiring an agent to it:
If Inspector asks for transport type, choose streamable HTTP.
Verify Tools
After authentication, confirm the MCP client can list tools from the developer server. In Claude Code, use /mcp; in MCP Inspector, connect to the hosted URL and open the tools list.
Expected Developer MCP tool areas include:
- Tool draft creation and updates
- Tool validation
- Tool version creation
- Compiler and Processor validation
- Ontology Object Type and tag lookup
- Tool-development guidance resources and prompts
Author a Tool with Developer MCP
Developer MCP gives an MCP client the context and validator loops it needs to turn tradecraft into a bounded, versioned Tool. The client can help research and implement a Tool, but it should not publish until you review the result and explicitly confirm publication.
Use this lifecycle:
- Research the capability. Search published Tools for two or three similar examples. Compare their names, intent, risk level, parameters, target types, and generated Ontology types.
- Look up the Ontology. Search and load the exact Object Type definitions before writing a Processor. Use the returned properties and link names rather than guessing constructors or relationships.
- Define the contract. Describe the Tool’s behavior, access, risk, typed parameters, target types, supported platforms and architectures, generated types, success criteria, and examples. Tags must use existing tag RIDs, never free-text labels.
- Validate the definition. Run definition validation first. Fix errors before writing or testing execution code.
- Save a draft. Create a draft after the definition is valid enough to preserve. Retain its
draft_idfor later updates and publication. - Validate the Compiler. Dry-run the Compiler with representative typed inputs and targets. Inspect the planned Script, CLI, or Courier execution before it reaches a Jackal.
- Validate the V3 Processor. Run the Processor against representative
payloador namedsignals. Confirm it returns durable Ontology Objects and links, not execution wrappers or raw diagnostics. - Repeat the full sequence. After a fix, rerun the failed validator and then definition, Compiler, and Processor validation.
- Publish with confirmation. Read the pre-publish checklist, review remaining warnings, and explicitly confirm publication. New Tools publish from a draft; existing Tools publish through the version-update flow.
The server exposes resources for each part of this loop: platform concepts, Tool-development guidance, examples, a validation workflow, and a pre-publish checklist. A capable MCP client should read these before it drafts or publishes a Tool.
Prompt an MCP client
Use a prompt that makes the safety and validation requirements explicit:
Troubleshooting
If the client cannot connect, confirm the URL is the hosted instance URL and ends in /developer/mcp.
If Codex does not show the server, confirm the entry is in ~/.codex/config.toml under [mcp_servers.developer], not in .mcp.json.
If Claude Code does not show the server, run claude mcp list from the repo root. Project-scoped .mcp.json servers may stay pending until you trust the workspace and approve them in an interactive claude session.
If the OAuth browser flow fails, check that you are using the right instance and that the instance’s OAuth client allows loopback redirects for native MCP clients.