How It Works

MCPify exposes one catalog of tools through three surfaces. Every surface shares the same registry, the same security gate, and the same output sanitization - so a tool behaves identically no matter how an agent reaches it.

The three surfaces

1. In the browser (WebMCP)

On any front-end page, MCPify registers its enabled tools with the browser's model-context API:

// Simplified - MCPify does this for you.
document.modelContext.registerTool(tool, { signal });

A WebMCP-capable agent running in that page can then discover and call the tools directly. MCPify tries the current API first and falls back to older shapes where needed, so it works across browser versions without configuration.

2. Over REST

Every tool is also a REST endpoint under the mcpify/v1 namespace. This is what non-browser agents (server-side assistants, scripts, automation platforms) use.

Method	Endpoint	Purpose
GET	/wp-json/mcpify/v1/manifest	List all enabled tools and their schemas
GET	/wp-json/mcpify/v1/tools/{tool}	Get one tool's definition
POST	/wp-json/mcpify/v1/execute	Run a tool ({ "tool": "...", "params": { ... } })
POST	/wp-json/mcpify/v1/call/{tool}	Run a tool by name in the URL ({ "params": { ... } })
GET	/wp-json/mcpify/v1/openapi	OpenAPI 3 description of all tools
GET	/wp-json/mcpify/v1/discovery	Machine-readable discovery document

3. As OpenAPI

The /openapi endpoint returns a standard OpenAPI 3 document generated from the tool schemas. Point a Custom GPT Action (or any OpenAPI-driven client) at it and the agent gets a typed description of every tool with no manual mapping.

Discovery

Agents need to find the tools before they can use them. MCPify advertises them in two standard ways:

• RFC 8288 Link headers and <link> tags on your pages point to the manifest and OpenAPI documents.
• The /discovery endpoint returns a single JSON document tying it all together.

This means a capable agent can land on any page of your site and follow the links to the full tool catalog.

The request lifecycle

Every tool call - browser, REST, or OpenAPI - flows through the same pipeline:

1. Resolve - the dispatcher looks up the named tool in the registry. An unknown tool name returns a not_found error.
2. Authorize - the access gate checks the tool's required tier (public read, authenticated, or capability) and, for write tools, a valid same-session nonce. See Security.
3. Rate-limit - per-caller and global limits are applied. Over the limit returns a rate-limit error instead of running the tool.
4. Validate - the input is checked against the tool's JSON Schema. Invalid input is rejected with a clear error before any work happens.
5. Execute - the tool runs against WordPress or WooCommerce using core APIs (HPOS-safe for WooCommerce).
6. Sanitize - the output is cleaned before it is returned, so stored HTML cannot carry script or injected instructions to the agent.

Response shape

All surfaces return the same envelope.

Success:

{
  "success": true,
  "data": { "results": [] }
}

Failure:

{
  "success": false,
  "error": { "code": "invalid_params", "message": "A human-readable reason." }
}

Because the shape is consistent, an agent can handle any tool's result the same way.

Design in one line

One registry of typed tools, one security gate, three transports - so you configure security and availability once and it holds everywhere.