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:

https://<instance-host>/developer/mcp

Configure Codex

Codex configures MCP servers in ~/.codex/config.toml. Add a developer entry for your instance:

[mcp_servers.developer]
url = "https://<instance-host>/developer/mcp"
enabled = true

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:

claude mcp add --transport http --scope project developer https://<instance-host>/developer/mcp

That writes or updates .mcp.json in the repo:

{
"mcpServers": {
"developer": {
"type": "http",
"url": "https://<instance-host>/developer/mcp"
}
}
}

For a private, per-user Claude Code config instead, omit --scope project:

claude mcp add --transport http developer https://<instance-host>/developer/mcp

Run Claude Code from the repo root:

claude

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:

npx @modelcontextprotocol/inspector https://<instance-host>/developer/mcp

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:

  1. 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.
  2. 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.
  3. 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.
  4. Validate the definition. Run definition validation first. Fix errors before writing or testing execution code.
  5. Save a draft. Create a draft after the definition is valid enough to preserve. Retain its draft_id for later updates and publication.
  6. 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.
  7. Validate the V3 Processor. Run the Processor against representative payload or named signals. Confirm it returns durable Ontology Objects and links, not execution wrappers or raw diagnostics.
  8. Repeat the full sequence. After a fix, rerun the failed validator and then definition, Compiler, and Processor validation.
  9. 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:

Build a Method Tool for [capability]. First, use Developer MCP to find similar
Tools and inspect the Ontology schemas needed for its output. Design the Tool
from its durable Ontology discoveries backward. Keep its parameters minimal and
typed, describe all network, filesystem, and credential access, and choose an
accurate risk level. Write a deterministic Compiler and a V3 Processor that
returns generated Ontology Objects. Validate the definition, Compiler, and
Processor with representative inputs and output. Do not publish until I review
the final definition and explicitly ask you to publish it.

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.

SymptomCauseFix
Tag validation failsThe definition used a label instead of a tag RIDLook up tags and use the returned id value
Compiler rejects a parameter typeThe definition used an unsupported enum-like shapeUse a STRING parameter and validate allowed values in the Compiler
Source fails in the sandboxThe Compiler or Processor imports modules or uses a name beginning with _Use the injected SDK symbols and public helper names
Processor creates no graph ObjectsgeneratesTypes or success criteria do not match the Processor outputDeclare every generated type and align success criteria with the created Object
Courier Processor receives no outputThe workflow action did not declare a named Signal outcomePass signal to first-class actions or declare the custom action’s step outcome
Courier dry-run cannot hydrate a targetThe validator received an object-selection wrapper instead of a mock ObjectPass an inline mock Ontology Object with its type and properties