Mulder
Documentation

Keep authority in your application.

Mulder validates tool calls; your server authenticates, authorizes, approves, and executes them.

Security

The browser receives tool descriptions, not API credentials. Server-backed calls return to your application’s companion route, where your application applies its normal security policy. Static calls go directly to the configured public API.

Authority boundaries

  1. Discovery. Only operations with x-webmcp-enabled: true become tools.
  2. Validation. Mulder rejects unknown, missing, invalid, and out-of-range input.
  3. Authentication. Your application identifies the current user or session.
  4. Authorization. Your application decides which resources that identity may access.
  5. Approval. A write also needs x-webmcp-approval-required: true and a prepareWrite implementation.
  6. Execution. Your existing API performs the operation and filters the result.

Reads and writes

GET -> validate -> authorize -> dispatch
POST or DELETE -> validate -> authorize -> prepareWrite -> approved execution
Annotations such as readOnlyHint and destructiveHint are hints, not authorization.

Credential custody

The complete companion keeps calls in your server application. Static mode is different: it calls a public CORS-enabled API directly, always omits credentials, and cannot expose writes.

Keep API keys, cookies, capabilities, and approval secrets on the server or in the browser’s normal secure session. Do not place them in OpenAPI descriptions, HTML, tool results, or tool annotations.

What Mulder does not prove

  • Which browser agent made a call.
  • That a signed-in user may access a requested resource.
  • That a write was approved by a person.
  • That an API response is safe to expose.

Start typing to search.