Pizza Developer
Pizza Developer is where your project's plan lives.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноМожет изменять данные
Что умеет
- 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
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
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.
Как подключить
Как подключить Pizza Developer к Claude
Адрес сервера, который нужно вставить в настройках Claude:
https://pizzadeveloper--hector-codes92.run.tools
- Откройте Claude (сайт claude.ai или приложение для компьютера).
- Перейдите в Настройки → Коннекторы (в английском интерфейсе: Settings → Connectors).
- Нажмите Добавить пользовательский коннектор (Add custom connector).
- Вставьте адрес сервера, скопированный ниже, в поле URL удалённого MCP-сервера и нажмите Добавить.
- В чате нажмите + → Коннекторы и включите новый коннектор.
Пользовательские коннекторы доступны на тарифах Free, Pro, Max, Team и Enterprise. На Free можно добавить только один. В Team и Enterprise коннектор сначала добавляет владелец организации в Настройки организации → Коннекторы.
Авторизация
После нажатия Добавить откроется окно входа в сервис. Войдите под своим аккаунтом и подтвердите доступ. Пароль Claude не видит.
Как подключить Pizza Developer к ChatGPT
Адрес сервера, который нужно вставить в настройках ChatGPT:
https://pizzadeveloper--hector-codes92.run.tools
- Откройте ChatGPT в браузере (chatgpt.com). Нужен тариф Plus, Pro, Business, Enterprise или Edu.
- Один раз включите режим разработчика: Настройки → Приложения → Дополнительные настройки → Режим разработчика (Settings → Apps → Advanced settings → Developer mode).
- Откройте Настройки → Коннекторы и нажмите Создать (Create).
- Заполните форму: Название (любое), Описание (одна фраза, что делает сервис), URL MCP-сервера (скопируйте ниже).
- В поле Аутентификация выберите OAuth, если сервис требует вход, иначе Нет. Нажмите Создать.
- В новом чате откройте + → Приложения/Коннекторы и включите коннектор.
Название раздела у OpenAI менялось (Connectors → Apps/Plugins). Если пункт называется иначе, ищите «режим разработчика» в настройках. В рабочих пространствах Business/Enterprise администратор должен разрешить пользовательские коннекторы.
Авторизация
При первом использовании ChatGPT откроет окно входа в сервис. Войдите и подтвердите доступ.
Как подключить Pizza Developer к Cursor
Адрес сервера, который нужно вставить в настройках Cursor:
https://pizzadeveloper--hector-codes92.run.tools
Быстрый способ: нажмите кнопку Открыть в Cursor ниже, Cursor сам предложит добавить сервер.
Вручную:
- В Cursor откройте Settings → Cursor Settings → MCP и нажмите Add new global MCP server.
- Вставьте JSON, скопированный ниже, в открывшийся файл
~/.cursor/mcp.json(для одного проекта:.cursor/mcp.jsonв корне проекта). - Сохраните файл. Сервер появится в списке MCP; при необходимости пройдите авторизацию по кнопке рядом с ним.
Авторизация
Если сервис требует вход, рядом с сервером в списке MCP появится кнопка авторизации.
Список инструментов сервера (60)
Технические названия из tools/list. Нужны только разработчикам.
| 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. |