Website → MCP server for your AI agent

On authorization. Writ runs on your own accounts, with your own credentials and data, on sites you are authorized to use.

AI agents are only as capable as the tools they can call. The Model Context Protocol (MCP) is how an agent discovers and invokes those tools. The catch: most of the software your work depends on has no API, so it has no tool, and the agent is stuck. Here is how to give an agent a real tool for any website.

What MCP is, in one paragraph

MCP is a small, open protocol for connecting AI models to tools and data. A client (Claude, Cursor, your own agent) connects to an MCP server, which advertises a set of typed tools. The model can then call a tool with structured arguments and get a structured result back. It is the clean, standard interface agents have been missing.

Why most sites are not MCP tools yet

To be an MCP tool, a capability needs a callable interface. A REST API can become one easily. But the supplier portal, the internal admin panel, the booking system behind a login: none of those have an API, so none of them can be a tool. That is exactly the gap Writ fills.

Turning a site into a tool

You build a workflow once (by recording the task in a real browser, describing the goal to AI, or discovering the underlying calls) and publish it. Writ exposes it as a REST endpoint at /v1/{slug}/{path} and as an MCP tool, from the same definition.

mcp config (Claude / Cursor) · json

{
  "mcpServers": {
    "writ": {
      "url": "https://api.usewrit.app/mcp",
      "headers": { "Authorization": "Bearer wt_8f3a…" }
    }
  }
}

Connecting Claude, Cursor, and other clients

Drop that config into your MCP client and your published workflows appear as tools. The agent reads the tool's typed inputs and calls it like any other function, except this tool drives a real browser session on a site that never had an API.

agent transcript · text

User: pull this month's open invoices from the supplier portal
Agent → tool: writ.portal_export({ account_id: "AC-19284", since: "2026-06-01" })
tool → agent: { invoices: [ { id: "INV-5521", amount: 1840.00 }, … ] }
Agent: You have 2 open invoices totaling $2,460.50.

Keeping agent actions safe

Giving an agent the ability to act is powerful, so the controls matter. Writ runs the workflow on your own account, and the agent never sees your credentials, which stay encrypted at rest. A dry-run preview and a confirm-gate are on by default, and write-style actions can be held for your approval, so an autonomous action always stays inside limits you set.

Action is gated, not assumed. Read-style tools are safe to expose broadly. For actions that spend or commit, pair the tool with a spend cap, a dry-run, and an approval gate. The agent proposes; your rails decide.

The payoff: your agent gains a tool for any authenticated site, with the same authorization and spend controls as a human operator. See how the MCP layer works

Give your agent a tool for any site

Publish a workflow as an MCP tool, callable with a wt_ key.

Get started Explore MCP

Common questions

Do I need to write an MCP server myself?

No. You build a workflow in Writ - by recording, describing, or discovering it - and publish it. Writ hosts the MCP server and exposes your workflow as a typed tool.

Can the agent see my credentials?

No. The agent calls the tool; Writ runs the workflow on your own account with your stored secrets. Credentials are encrypted at rest and never exposed to the AI or in logs.

Which MCP clients work?

Any MCP-capable client - Claude, Cursor, and others - by pointing it at the Writ MCP server with a wt_ key. The same tool is also callable as plain REST.

Website → MCP server: give your AI agent a tool for any site