Pizza Developer
Pizza Developer is where your project's plan lives.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeCan modify data
What it can do
- List Projects: List every project the signed-in user owns or that has been shared with them.
- Get Project: Get one project's own details: name, description, links, tags, Public Delivery Page settings (deliveryPageSettings, socials, publicDeliveryPage, showcase listing), and archived state. For
- Create Project: Create a project from its details, with any Ideas the vibe coder supplied. Only the name is required; Ideas, Batches, Works, Deliveries, a Workflow, a repository, and a live URL can al
What data it sees
Do you need an account
No: the server works without sign-in
Pizza Developer is where your project's plan lives. The MCP server lets your coding agent read and update that plan: your priorities, your rules, and the route each kind of request should take.
How to connect
How to connect Pizza Developer to Claude
The server address to paste into Claude settings:
https://pizzadeveloper--hector-codes92.run.tools
- Open Claude (claude.ai or the desktop app).
- Go to Settings → Connectors.
- Click Add custom connector.
- Paste the server address copied below into Remote MCP server URL and click Add.
- In a chat, click + → Connectors and switch the new connector on.
Custom connectors are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). On Team and Enterprise an organization Owner adds the connector first under Organization settings → Connectors.
Authorization
After you click Add, a sign-in window for the service opens. Sign in with your own account and approve access. Claude never sees your password.
How to connect Pizza Developer to ChatGPT
The server address to paste into ChatGPT settings:
https://pizzadeveloper--hector-codes92.run.tools
- Open ChatGPT in a browser (chatgpt.com). A Plus, Pro, Business, Enterprise or Edu plan is required.
- Turn on developer mode once: Settings → Apps → Advanced settings → Developer mode.
- Open Settings → Connectors and click Create.
- Fill in the form: Name (anything), Description (one line about what the service does), MCP server URL (copy it below).
- Under Authentication choose OAuth if the service requires sign-in, otherwise None. Click Create.
- In a new chat open + → Apps/Connectors and enable the connector.
OpenAI has renamed this section before (Connectors → Apps/Plugins). If the label differs, search settings for "developer mode". On Business/Enterprise workspaces an admin must allow custom connectors first.
Authorization
On first use ChatGPT opens the service's sign-in window. Sign in and approve access.
How to connect Pizza Developer to Cursor
The server address to paste into Cursor settings:
https://pizzadeveloper--hector-codes92.run.tools
Fastest: click Open in Cursor below and confirm the prompt.
Manually:
- In Cursor open Settings → Cursor Settings → MCP and click Add new global MCP server.
- Paste the JSON copied below into
~/.cursor/mcp.json(per project:.cursor/mcp.jsonin the repo root). - Save the file. The server appears in the MCP list; authorize it there if asked.
Authorization
If the service needs sign-in, an authorize button appears next to the server in the MCP list.
Server tool list (60)
Raw names from tools/list. Only developers need these.
| list_projects | List every project the signed-in user owns or that has been shared with them. |
| get_project | Get one project's own details: name, description, links, tags, Public Delivery Page settings (deliveryPageSettings, socials, publicDeliveryPage, showcase listing), and archived state. For next steps call get_project_state; for records use list_batches, search_works, list_ideas, and list_deliveries; instruction documents are the pizzadeveloper://projects/{projectId}/instructions/{documentId} resources. |
| create_project | Create a project from its details, with any Ideas the vibe coder supplied. Only the name is required; Ideas, Batches, Works, Deliveries, a Workflow, a repository, and a live URL can all be added later. Supplied Ideas keep their order, and up to the first two become planning input. Everything is validated before anything is written. |
| get_project_state | Get the planning state needed to resume work on one project. nextAction names the tool to call next. When the project has workflows, it lists them with their open runs and nextAction is start_workflow; resume_workflow continues an open run that already covers the request. Otherwise nextAction is begin_work (resume the active Work, claim the next one, or start the next planned Batch), finish_work (close a Batch whose Works are all done, with batchSummary, on developing.finishWorkId), create_work (add a Work to a developing Batch that has none), create_batch_plan (plan from the listed Ideas), or project_complete when nothing is left. It reports only Pizza Developer records, never repository, runtime, Git, deployment, or agent presence state. |
| list_workflows | List the project's workflows with each one's name, description, entry points (idea, batch, and/or delivery), whether it can run, and its graph. A project can have several workflows, each described by the kind of request it handles. Archived workflows are left out unless includeArchived is true. |
| get_workflow | Get one saved workflow with its name, description, nodes, connections, and the instruction and ruleset IDs attached to each connection. |
| create_workflow | Create a named workflow: a route of stages that requests in the project follow. name is unique in the project; description says which requests it handles. Nodes are Start, optional Idea, Batch, optional Delivery, optional Workflow (the step that improves the Workflow itself after a run), and Finish. Start can connect to an existing Batch without Idea, and Batch can connect to Workflow or Finish without Delivery. Start can also connect to Delivery, for a workflow that only creates or adds to a Delivery: Start to Delivery to Finish, or Start to Delivery to Workflow to Finish, with no Batch node. Each edge.data must contain instructionDocumentIds (existing project document IDs) and contextKinds (features and/or dictionary; each adds only a short outline, top-level feature names or dictionary words, that the agent expands with the read tools). edge.data may also carry rulebookIds, an ordered list of the project's ruleset IDs attached to that connection; leaving it out attaches none. Select documents on connections; do not create Instructions, Dictionary, or Features nodes or put text on lines. Projects work without a Workflow. |
| update_workflow | Edit one workflow. Pass nodes and edges together to replace its graph, and name or description to change its details; omitted parts stay as they are. Nodes are Start, optional Idea, Batch, optional Delivery, optional Workflow (the step that improves the Workflow itself after a run), and Finish. Start can connect to an existing Batch without Idea, and Batch can connect to Workflow or Finish without Delivery. Start can also connect to Delivery, for a workflow that only creates or adds to a Delivery: Start to Delivery to Finish, or Start to Delivery to Workflow to Finish, with no Batch node. Each edge.data must contain instructionDocumentIds (existing project document IDs) and contextKinds (features and/or dictionary; each adds only a short outline, top-level feature names or dictionary words, that the agent expands with the read tools). edge.data may also carry rulebookIds, an ordered list of the project's ruleset IDs attached to that connection; leaving it out attaches none. Select documents on connections; do not create Instructions, Dictionary, or Features nodes or put text on lines. Updates made during a run's self-improvement stage are described in the report that closes that step. Open runs keep their frozen revision. Graph writes are refused while a vibe coder has the workflow open for editing in the browser, and archived workflows must be restored first. |
| archive_workflow | Archive a workflow the vibe coder no longer uses. It stops being offered for new runs; an open run of it continues and its history stays. |
| unarchive_workflow | Unarchive a workflow so it can be edited and run again. |
| delete_workflow | Permanently delete a workflow together with all of its runs, step reports, and revisions. Batches, Deliveries, and tool calls it touched stay. confirmName must equal the workflow's exact name. archive_workflow hides a workflow and keeps its history. |
| start_workflow | Start a run of one workflow from an Idea, a planned existing Batch whose Work has not begun, or a new batch plan (name and ordered works, as in create_batch_plan). A workflow that starts at Delivery takes none of them: the run begins on its Start to Delivery connection, and create_delivery or assign_batch_to_delivery completes it. With batch, the Batch is planned and the run started in one call, its review step is skipped, and edgeId can name the Batch stage route; a retry while that run is open returns the same run. A Batch run governs that Batch's Work queue until it is ready. The run is pinned to the workflow's current revision and returns its current step. Each instruction body is sent once per run; a document already sent earlier in the run comes back as a uri reference. |
| resume_workflow | Reconcile and read an open workflow run, then deliver its current step. Each workflow has at most one open run; name it with runId or workflowId when several are open. Pass an available edgeId before reporting to choose a configured branch, including one that names the optional stages it bypasses. Without an edgeId, a step already delivered is re-sent in full, which is how a new session recovers its instructions; other calls return only the step's instruction titles after its first delivery. |
| report_workflow_step | Report the agent client's outcome and optional measured costs for a workflow step that has no expected lifecycle tool, a failure, the self-improvement step, or the client score. A step with an expected lifecycle tool is completed by that tool, which also accepts the client metrics, so it needs no report; failed blocks a step for another attempt. Optional stages are bypassed only by choosing a configured available edge with resume_workflow before entering them; once entered, every step is required. A completed self-improvement report closes that step and its reason describes what changed and why, or why nothing did. Research content is never stored. When one route follows, the response carries the next step's instructions; when several do, choose one with resume_workflow and its instructions arrive then. |
| cancel_workflow | Cancel an open workflow run without deleting its recorded route or measurements. A truthful reason is required. |
| update_public_delivery_page | Set whether the project's Public Delivery Page shows dates and configure supported social profiles: YouTube, X, Discord, LinkedIn, Instagram, TikTok, Bluesky, Threads, Twitch, Spotify and Apple Music. Owner-only. Read current values with get_project. Omitted fields stay unchanged; empty strings remove profiles. Custom links are not supported. Upload or remove logo/cover images in the app (PNG/JPG, 4 MB); image references cannot change here. Does not publish the Public Delivery Page. |
| update_project | Update a project's own details. Only the fields you provide change. Owner-only. Instruction documents change through update_instruction. |
| create_instruction | Create an instruction document on a project, freely titled (there is no fixed set), with its full text when known. Titles are unique within the project. During an active workflow run, instruction changes are accepted only in its self-improvement stage. Returns its id for update_instruction. |
| update_instruction | Rename an instruction document or rewrite its text whole. Only supplied fields change; content replaces the entire text, and an empty string clears it. Earlier text stays in the document's revision history. Read current text from its pizzadeveloper://projects/{projectId}/instructions/{id} resource first. During an active workflow run, instruction changes are accepted only in its self-improvement stage. |
| archive_instruction | Archive an instruction document. It leaves the active list and the listed instruction resources but keeps its content and revision history. Only archived instructions can be deleted. During an active workflow run, instruction changes are accepted only in its self-improvement stage. |
| unarchive_instruction | Unarchive an instruction document, returning it to the back of the active list. |
| delete_instruction | Permanently delete an archived instruction document, together with its revision history. Active instructions must be archived first. |
| reorder | Set the manual order of one kind of record, first shown first. orderedIds lists the records; parentId names where they live: - project: your own projects on the dashboard; no parentId; a subset keeps every other project in place. - idea: every active Idea; parentId is the project; the first two are planning input. - batch: every planned Batch; parentId is the project; developing and ready Batches keep their place. - work: every Work in the Batch; parentId is that Batch, which must not be ready. - instruction: every active instruction; parentId is the project; during a workflow run, accepted only in its self-improvement stage. - dictionary_term: every active term; parentId is the project. - rulebook: every ruleset; parentId is the project. - rule: every rule in one ruleset; parentId is that ruleset. |
| archive_project | Archive a project. Hides it from the default dashboard view but keeps it reachable (list_projects and search still find it). |
| unarchive_project | Unarchive a project, restoring it to the default dashboard view. |
| delete_project | Delete a project and everything under it (batches and works). |
| list_batches | List a project's batches as bounded summaries (id, number, name, status, and queue position). Call get_batch for rationale, summary, and Work detail. Batches are numbered sequentially per project (1,2,3…). |
| get_batch | Get one batch. |
| create_batch_plan | Create a planned batch and its planned works in one call. This is the normal way to plan a batch once its scope is agreed. The batch name is 1 to 3 lowercase words joined by single hyphens, like dark-mode-toggle. The batch takes the next sequential number and queue position; works start planned in the order given, and the result carries each work's batch-scoped reference (like `4-1`), ready for commit messages. create_work adds a Work to an existing Batch. When several workflow runs wait for a Batch, pass runId to plan it for that run. In a workflow run, this completes the planning step (and an open Evaluate-the-idea step), and edgeId can name the Batch stage route so no separate resume_workflow call is needed. |
| update_batch | Edit a batch's name, rationale, or change summary; only supplied fields change, and an empty string clears rationale or summary. A name is 1 to 3 lowercase words joined by single hyphens, like dark-mode-toggle. Rationale is the vibe coder's stated reason for building the batch, in one or two plain sentences. Summary is what the batch changed, drafted from its recorded work, in two or three factual sentences. A ready batch refuses rationale and summary edits. Status moves through begin_work, finish_work, and revert_batch, and batch numbers are immutable. |
| delete_batch | Delete a batch. Batches that still have works can't be deleted. |
| revert_batch | Move a batch one step back as an undo: developing → planned, and only while every work inside it is still planned. Ready batches are frozen history and can't be reverted. |
| list_deliveries | List a project's deliveries, newest shipped first, as bounded summaries: id, public version, shipped date, batch and Work counts, and whether it has a presentation. Lists active deliveries; pass archived=true for archived ones. Call get_delivery for rationale, summary, and assigned batches. |
| get_delivery | Get one delivery by id, with its shipped date, rationale, summary, assigned batches, work progress, and archived state. |
| create_delivery | Create a shipped public delivery from selected undelivered batches: batches no other delivery carries, including ready Batches of several finished workflow runs. Supply its version label (free-form; semver like 2.4.0 is common but not required) and a factual summary. To record a release that shipped before the project used Pizza Developer, omit batchIds and pass shippedAt, the real past ship date (ISO date or date-time); without shippedAt it ships now. A delivery without batches never completes a workflow run's Delivery stage. In a run of a workflow that starts at Delivery, any ready Batches no delivery carries can go in, and the call completes the run's Delivery stage. When the project has a workflow that starts at Delivery, create_delivery outside a workflow run is refused and the refusal names that workflow. |
| update_delivery | Edit a delivery's own record (version, rationale, summary, ship date, or which undelivered batches ride in it). Only supplied fields change; pass an empty string to clear a text field. batchIds, when present, is the full desired set of batches and replaces the current one. shippedAt corrects when it shipped (ISO date or date-time, not in the future). The version is a free-form label and must stay non-empty and unique within its project. |
| update_delivery_presentation | Save a delivery's release presentation: scenes built only from the listed elements, played on the Public Delivery Page in the brand's style. The story comes from the delivery summary and real product copy; brand colors, radius, and font come from the product's own logo and styles. The logo uploaded on the project's public page is the only brand mark shown, and the presentation holds no source code. Release notes lead with the changes element for the delivery's headlines and show what moved with before-after or navigation. Every scene lasts at least its reading time, about 1.5 seconds plus one second per three words shown, and at least 3 seconds. Scenes last whole seconds, at most 60 seconds in total. Replaces the current presentation; earlier versions stay restorable in the app. An invalid presentation returns field-level errors to fix. |
| delete_delivery_presentation | Delete a delivery's current release presentation, so the Public Delivery Page shows none. It stays restorable from the presentation history in the app. |
| get_delivery_presentation | Read a delivery's current release presentation document, or null when it has none. |
| assign_batch_to_delivery | Put a ready batch in a delivery, or take it out. Pass deliveryId to assign, omit to unassign. Only a ready batch no delivery carries can be assigned. Take it out of its current delivery first. At a workflow run's Delivery stage, assigning every ready Batch of the run to one existing Delivery completes the stage instead of create_delivery. In a run of a workflow that starts at Delivery, adding any ready Batch no delivery carries to an existing Delivery completes the stage. |
| archive_delivery | Archive a delivery. It keeps its record and batches but leaves the Deliveries page, the Public Delivery Page, and the showcase, and remains readable through list_deliveries with archived=true. |
| unarchive_delivery | Unarchive a delivery, returning it to the Deliveries page and the public surfaces it was listed on. |
| delete_delivery | Delete a delivery. Its batches come out of it unassigned, ready to go into another one; they are not deleted. Deleting a shipped delivery rewrites public history. |
| search_works | List or find Works, newest-updated first, as trimmed rows (id, reference, title, size, status, batchId, projectId; call get_work for full detail). Pass projectId to list one project's Works; query searches title and description across every project you can reach, or inside that project. `status` is planned, in-progress, or done. `reference` is the batch-scoped name a Work is known by outside this app: `1-2` is work 2 of batch 1. |
| get_work | Get one work item. `reference` is the batch-scoped name it is known by outside this app: `1-2` is work 2 of batch 1, the same reference a commit message carries. |
| create_work | Create a Work in a Batch that is not ready. It always starts planned; begin_work starts it. In a workflow run, the Batch plan with the new Work is checked against the rulesets on the connection the run entered Batch on, until one of its Works is done; a Must rule that does not pass refuses the write. |
| begin_work | Begin repository implementation in one boundary call. Pass workId to claim that Work, or projectId to resume the active Work or claim the next ordered one. Each open workflow run builds its own Batch; pass runId to work in a specific run when several are open. If nothing is developing there, the next planned batch is started automatically when it contains implementable work. Returns the Work brief and the project's own instruction documents that apply to it. |
| finish_work | Record completed repository implementation in one boundary call. Replaces the Work description with the factual implementedSummary and marks it done. If this closes the batch, batchSummary closes it in the same call; otherwise the response asks only for that missing summary. Calling it again on a done Work with batchSummary closes a Batch left open. A Work left planned or in progress inside a ready Batch is finished here too. Use it once implementation is complete. |
| update_work | Edit a Work's planning details. Only supplied fields change. batchId deliberately moves a planned Work. status accepts only planned, to send a started Work back to the queue; a Work starts only through begin_work and finishes only through finish_work. In a workflow run, a change to the title, description, labels, size, or Batch is checked as part of that Batch's plan against the rulesets on the connection the run entered Batch on, until one of its Works is done; a Must rule that does not pass refuses the write. |
| update_handoff_note | Replace the handoff note on the Work being implemented, so another session can continue it: what is done, what remains, files touched, and whether changes are uncommitted. begin_work returns it to whoever resumes the Work; finish_work clears it. Pass an empty note to clear it. |
| delete_work | Delete a work item. |
| list_ideas | List a project's ideas in one state as bounded summaries in the vibe coder's own order, front first. state is active by default; archived ideas were completed; declined ideas were decided against and carry the reason. Only active ideas are planning input; their first two positions are the planning ideas. Call get_idea for full content. |
| get_idea | Get one idea with its full summary and content. |
| create_idea | Create a project idea with a required short name of at most 20 characters. Summary and content are optional and are never generated. Impact is semantic product scope, not priority. A new idea joins at the back of the order; move it forward with reorder. A name matching a declined idea is refused. |
| update_idea | Update an idea's short name of at most 20 characters, optional detail, or impact. Nothing is generated. Only supplied fields change. Order is separate: move an idea with reorder. Archiving, declining, and restoring Ideas don't run rules. |
| archive_idea | Archive a completed idea. It leaves the active planning order but keeps its content and remains available through list_ideas with state archived. |
| decline_idea | Decline an idea the vibe coder decided against, with their reason in their own words. It leaves the planning order and is listed with declined ideas. Declining an already declined idea replaces its reason. |
| restore_idea | Restore an archived or declined idea to the back of the active planning order. |
| delete_idea | Permanently delete an archived or declined idea. Active ideas must be archived or declined first. |
| list_dictionary_terms | List a project's active dictionary terms as bounded summaries (id, word, and aliases) in the vibe coder's own order. Pass archived=true to read archived terms instead. Call get_dictionary_term for the approved definition. |