https://api.pre.dev/mcp, over Streamable HTTP. It runs pre.dev’s specification and browser tools. Searching this documentation is a separate MCP server, https://docs.pre.dev/mcp, which needs no key.
Connect once to use specification generation, project plans and browser automation. Setup instructions cover authentication and client configuration.
Call tools/list after initialization for the live input schemas. GET /mcp/info is a human-readable service inventory; it is not the protocol’s tool-discovery method.
Tool inventory
Generation and browser execution consume credits. Retrieval and listing do not launch new work. The server marks browser execution as potentially destructive because a task can click, submit forms, or change data on external sites.
The
browser_agent tools run tasks on pre.dev’s cloud browsers. To let your coding agent drive the Chrome on your own computer, with your profiles and logins, use Browser Agents Local: a separate, open-source MCP server that runs on your machine and provides its own chrome_* tools.fast_spec and deep_spec
Both tools accept the same parameters:input, currentContext, file, or async fields. They may return before generation finishes. If the result provides a specification ID, call get_spec until its status is completed or failed.
Generation results are text, not the REST SpecResponse JSON envelope. A progress notification reaching 100 does not replace a terminal status check.
get_spec
specId is required. Use the ID returned by generation or listing. A successful structuredContent contains specId and status; it may also include endpoint, created, executionTimeMs, progress, specUrl, predevUrl, output, errorMessage, and creditsUsed, the credits recorded for the spec’s project so far.
output is specification Markdown, preferring the coding-agent variant. Status is pending, processing, completed, failed, or unknown. Optional values may be absent while generation is running.
A completed result also carries plan when its project has one: the project’s verified plan (the same object get_plan returns), and the text ends with the plan as Markdown.
list_specs
For nonempty pages,
structuredContent contains specs, total, hasMore, skip, and limit. Each entry uses specId, not REST’s _id. Use get_spec for the full body. An empty page returns a text-only result.
There is no find_specs MCP tool; use REST search.
get_plan
specId (from generation or listing) or projectId. The result is the project’s verified plan: what the app is for, each feature’s status from pre.dev’s checks, progress, what is left, whether it is ready to launch with a plain fix for each open item, where screens, API routes and stored data live in the code (file and line), and what the last change did.
The text content is the plan as Markdown, written for a coding agent to read before working on the project. structuredContent contains projectId, specId, plan and markdown; plan has the same fields as the REST plan and is null while the project has nothing planned or built yet.
An organization key reads its organization’s projects; any other key reads only its own. Another account’s ID returns an error result (
isError: true), the same as an ID that does not exist. Retrieval does not use credits.
browser_agent
Each task supports:
Limits apply to each task. Set explicit budgets for long flows; defaults can vary by task and execution mode. Your account’s in-flight limit also applies to the whole submission.
Synchronous execution returns a text summary, which truncates task data. Retrieve
browser_agent_get for full structured results. Async execution returns the ID in text so you can poll it.
The MCP tool has no stream or idempotencyKey input and no cancellation operation; closing the client does not stop browser work. It emits live notifications during synchronous execution when the client supports them. The same credit, batch-size, and account in-flight gates apply as in REST.
Extract structured data
browser_agent_get with that ID for the complete structuredContent, including results[i].data.
Run a longer workflow
For a multi-step workflow, usemode: "agent", give a concrete completion condition, and submit asynchronously:
browser_agent_get every few seconds. Stop when batch status becomes completed or failed, and inspect each task’s uppercase status. A completed batch does not mean every task succeeded.
browser_agent_get
id is required; includeEvents is optional and defaults to false. structuredContent contains the browser run, including individual task outcomes and extracted data. Set includeEvents to true to retrieve timelines and any available screenshots. During synchronous execution, clients with logging support also receive notifications/message; these are MCP notification envelopes, not REST SSE frames, and heavy event data may be shortened.
browser_agent_list
The structured result contains
total and batches. Each batch has id, status, total, completed, and totalCreditsUsed. Unlike REST listing, this tool does not return hasMore; compare your offset and page length with total.
Notifications and errors
The server sendsnotifications/message with params: { level, logger, data }. Browser messages contain a task index and event details; large screenshot and DOM values can be elided. Specification messages report phases such as start, generating, and packaging.
To receive notifications/progress, include a progressToken in the tools/call request’s _meta:
isError: true when the tool call itself fails. Specification tools can return an error in text without isError; inspect the content and retrieve the specification status where an ID is available. Disconnecting or cancelling notification delivery does not cancel the underlying browser run.
Deprecated aliases
The aliases remain registered for compatibility. Use the current names in new integrations. Credits, queue status, and live browser URL retrieval are available through REST rather than dedicated MCP tools.

