MCP Server Reference
Overview
Welcome to the DefProd MCP server documentation. This MCP server provides AI agents with access to DefProd's functionality and data. When AI agents interact with your product definition, the magic really starts to happen!
Tool Summary
The DefProd MCP server provides these tools:
- assessChangeRisk: Score a change against the risk rubric and record the assessment. Give severity, occurrence and detection on the 1-10 ordinal scales, each with the evidence behind it — an axis without evidence is rejected, because an unsupported score is not an assessment. Detection is INVERTED: 1 means certain to be caught before a customer sees it, 10 means silent. You do NOT supply the category. It is derived from the vector by a severity-weighted lookup and returned on the change; supplying one is rejected. The only way to move the category is to move an axis and evidence it. Before scoring, perform the lookups the rubric mandates: enumerate what the change touches (and whether any of it is billing, authentication, authorisation or tenant isolation) for severity; find the prior art and check docs/rules and the incident record for the failure pattern for occurrence; run coverage over the changed paths and name the test that would fail — or state that none exists — for detection. Scoring occurrence LOW because the subsystem is unfamiliar is the classic error: unfamiliarity is an argument for a HIGH occurrence. For a change involving a database migration, use overlay "dbm" and declare both writeSet and sideEffects. Empty arrays are permitted but must be stated explicitly. Reversibility is then DERIVED from those declarations and overrides your authored value unless you record a justification; both values are kept. Re-assess freely as the change progresses — the current assessment is replaced and the full history is kept in the change event trail. Assessing never moves the change through its pipeline and never disturbs recorded stage times. Re-assessing is also safe for the change's pipeline confirmation, in one direction only. A score that RAISES the category out of an auto-confirmed band clears the confirmation, so the record never states an oversight level the current assessment contradicts, and a fresh confirmation is then required. A score that LOWERS it leaves the stricter confirmation standing and does not auto-confirm the lighter band: an agent does not reduce oversight below an explicit human choice, so a fall is a proposal a person accepts by calling confirmChangePipeline. The trail records that the lighter selection was held rather than applied.
- cancelChange: Cancel a change (change-level). The position is preserved — a later reopenChange resumes exactly where it stopped. Any in-progress stage work is cancelled with it. The first cancellation stamps cancelledAt permanently. Shipped (frozen) changes cannot be cancelled. Emits changeCancelled.
- cancelChangeStage: Cancel in-progress stage work without finishing it — the stage returns to not started and the working actor is cleared; the change stays alive at the same position. The escape valve for a crashed agent or a human pulled away. Emits changeStageCancelled.
- confirmChangePipeline: Freeze onto the change, in full, the pipeline it runs under — every stage, whether it is enabled, and who drives it — together with the risk category that selected it. You do NOT supply the category, and you do NOT supply the pipeline. The category is read from the change's own current risk assessment and the pipeline is resolved from it; a change with no assessment is rejected, because there is nothing to resolve from. Assess first, then confirm. The record is deliberately self-contained rather than a reference to configuration: it must still name the pipeline this change was SELECTED for after the repository's configuration has been edited. It is not a record of what oversight the change actually received — that is answered per stage by the driver reported when the stage was stamped. Automation never lowers it. A re-assessment that falls below a band already confirmed leaves the stricter confirmation standing rather than replacing it, because an agent does not reduce oversight below an explicit human choice. Calling this tool, by contrast, always applies the change's current category — that is how a human accepts a proposed reduction. You may pass per-stage driver overrides ONLY where the change's repository sets allowConfirmedPipelineOverride. Where it does not, supplying them is rejected rather than quietly ignored, so you never believe you confirmed a pipeline you did not. Overrides target judgement stages only (design, define, code, test, review, merge, push) and may set human or agent, never cicd. Where a repository auto-confirms a band — low, unless it says otherwise — the pipeline is already confirmed as part of recording the assessment, and calling this is unnecessary for changes in that band. Re-confirm freely while the change is in flight: the record is replaced and the full history is kept in the change event trail. Confirming never moves the change through its pipeline and never disturbs recorded stage times. Whether the confirmed pipeline then GOVERNS the change is the repository's decision, not this call's: where the repo grants confirmed pipelines authority, the change runs under this pipeline and a later configuration edit cannot reach it; where it does not, the confirmation is recorded and drives nothing. Read effectivePipelineSource on the change to see which applies rather than inferring it.
- createArchitectureElement: Create a new architecture element
- createArea: Create a new product area
- createChange: Create a new change record. Creating a change is the accept gate: the record enters the pipeline with acceptance completed. Origin is an external reference (e.g. a JIRA key or brain intent), never a DefProd entity. An externally-sourced change whose origin is already carried by an ACTIVE change is rejected (duplicate promotion); a cancelled predecessor suggests reopenChange; shipped predecessors do not block.
- createProduct: Create a new product definition
- createRepo: Create a new repository connection
- createUserStory: Create a new user story
- deleteArchitectureElement: Delete an architecture element
- deleteArea: Delete a product area
- deleteChange: Delete a change record. Shipped changes are frozen and cannot be deleted — use cancelChange for cancelled work; delete is for records that should never have existed.
- deleteProduct: Delete a product definition
- deleteRepo: Delete a repository connection
- deleteUserStory: Delete a user story
- failChangeStage: Report in-progress stage work as failed — the stage is recorded as failed rather than returned to not started, so an attempt that did not succeed is never mistaken for one that never began. The change stays alive at the same position and can be retried by starting the stage again. The counterpart to cancelChangeStage, which is for deliberate abandonment. Emits changeStageFailed.
- finishCdRun: Report a CD run's terminal facts — outcome (shipped | failed | aborted), failing stage, stage timeline, and log tail (one-way, best-effort ingestion). On a successful production ship the server mints one release per delivered product; the pipeline never creates a release itself.
- finishChangeStage: Finish a pipeline stage. Omit `stage` and the server finishes the stage currently in progress (or, if idle, the next enabled stage). The caller reports the fact ("review is done") — the backend owns the workflow. Finishing an unstarted stage is legal (startedAt stays null = start unrecorded). Stamps the first-entry finishedAt; finishing `ship` freezes the record permanently; emits changeStageFinished. Optionally report `driver` — who actually drove this stage — on the same terms as startChangeStage. It is accepted here as well as there because a stage whose start was never reported (a CI-stamped stage, for one) would otherwise have no way to record one. The first report wins, so a driver already recorded at the start is not overwritten.
- getArchitectureForProduct: Get the architecture for a product
- getArchitectureTree: Get the architecture tree for an architecture
- getArea: Get a product area
- getBriefForProduct: Get the brief for a product
- getCdRun: Get a CD deployment run by id — its outcome, target environment, triggering commit, per-stage timeline and log tail.
- getChange: Get a change record by id, or by productId + key (key lookup tolerates zero-padding: CHG-7, CHG-07 and CHG-007 resolve to the same record).
- getChangeAnalytics: Read one period of change analytics for a team, a repository, or a single product — the investment mix, how long change work took from acceptance to production, and the risk and capability layers. Returns the chosen period AND the one before it, because the comparison that matters is a scope against its own previous period. Comparing scopes against each other is not supported and is not an omission: change granularity is a local convention, so counts do not travel between teams or products. Every headline figure counts only changes that SHIPPED inside the period, so accepting a large batch of new work does not move it. Newly accepted work is reported separately. Durations always arrive paired with the open-work count and age spread. A median computed over only the changes that finished is survivorship-biased and improves as a team gets more backed up, so it is never returned alone. Waiting time is attributed to what the change was waiting on — a person, an agent, or automated delivery — from the pipeline it ran under. That is a queue fact, never a claim about how much work a named individual did. A closed period is served from its frozen rollup where one exists, so a figure quoted from it does not later change; `isProvisional` is true for the current, still-running period.
- getEffectiveChangePipeline: Resolve a product's effective change pipeline: the repository-level default with the product's judgement-stage driver overrides applied. This is the same resolution the change stage engine uses, so agents and tools see the same enabled stages and drivers the UI shows.
- getProduct: Get a product definition
- getProductBySlug: Get a product definition by its globally-unique slug
- getRelease: Get a release (a per-product production-ship artifact) by id, including its version, the changes it delivered, and any release notes.
- getRepo: Get a repository by ID with discovered packages
- getUserStory: Get a user story
- linkProductToRepo: Atomically link an existing product to an existing repo.products[] entry discovered by the scanner
- listAreas: List areas for a product
- listCdRuns: List a team's CD deployment runs, newest first (every outcome — in progress, shipped, failed, aborted). Optionally narrow to runs that touched a given product, environment, or outcome. Returns a COMPACT SUMMARY per run: outcome, products, changes, triggering commit, environment, version, stage timeline and timings. It deliberately carries no log output — read a run's log tail from getCdRun. Results are a bounded slice and the response reports the true total so a slice is never mistaken for the whole set. This is the data behind the Deployments view.
- listChanges: List change records for a product, optionally filtered by stage, stage state, type, cancellation, or external origin reference (originSystem/originRef — e.g. find the change for JIRA ticket PROJ-123). Returns a COMPACT SUMMARY per change: identity, type, lifecycle position, the owning product, link counts, the assessed risk category and when the current stage began. It deliberately carries no long-form narrative (intent, design), no pipeline configuration and no risk evidence — fetch the full record for one change with getChange. Results are a bounded slice, newest-updated first, and the response reports the true total so a slice is never mistaken for the whole set.
- listProducts: List all product definitions
- listReleases: List a product's releases, newest first — the version each shipped, the changes it delivered, and any release notes. This is the data behind the per-product Releases view.
- listRepos: List repositories for a team
- listTeamChanges: List change records across every product in a team, optionally filtered by repository, product, stage, stage state, type, cancellation, or external origin reference. Returns the same COMPACT SUMMARY per change as listChanges — identity, type, lifecycle position, the owning product, link counts, the assessed risk category and when the current stage began — with no long-form narrative, pipeline configuration or risk evidence; fetch the full record for one change with getChange. Results are a bounded slice, newest-updated first, reporting the true total, and are limited to the products the caller may read.
- listUserStories: List user stories for a product
- moveArchitectureElement: Move an architecture element to a new parent and/or position
- patchArchitectureElement: Apply patch changes to an architecture element
- patchArea: Apply patch changes to a product area
- patchBrief: Apply patch changes to a product brief
- patchChange: Apply patch changes to a change record (content only; lifecycle position and cancellation are written solely via the stage-action cases; historical stage times are set or corrected via the setChangeStageTimes case, not here; shipped records are frozen)
- patchProduct: Apply patch changes to a product definition
- patchRelease: Edit a release. Only the human-authored notes changelog (/notes) is editable; version, delivered changes, source run and shipped date are immutable records of what actually shipped.
- patchRepo: Apply patch changes to a repository (e.g. update discovered packages, link packages to products)
- patchUserStory: Apply patch changes to a user story
- recordChangeDefect: Classify the defect a fix repaired, so risk predictions can later be scored against what actually happened. Applies to a change of type bug only. One classification per change, holding the MOST SEVERE defect the fix repaired: rank by who it affected — customer beats staff beats developer — and break ties by impact severity. A fix that repaired several defects records the one nearest the customer and lets the rest go; the number this produces is "customer-facing defects", not "defects". impactSeverity is scored on the SAME 1-10 anchors as the risk rubric's Severity axis, and for the same reason the assessment demands evidence: an unsupported score is not an assessment. Score it WITHIN the audience you named in affects — the anchors are written assuming a customer, so a staff-only defect breaking a core admin workflow reads as an 8 and wildly overstates its business impact. Never compare severities across audiences. foundBy is what actually exposed the defect, not what should have. It is the field that tells the team which gate to invest in, and it is the cheapest one here — you cannot fix a bug without already knowing how you found it. THE COMMIT IS THE THING TO SUPPLY, not the change. Give introducedInCommit from bisect or blame, and introducedInCommitTrailer as the Change: trailer read off that same commit; the change link, and how long the defect lay undetected, are derived from those. Do not look a change up yourself. Where the defect is in code that never worked there is no introducing commit — record age "base" and omit them both, rather than guessing. Recording a classification never moves the change through its pipeline, never disturbs stage times, and never blocks a fix from shipping. It can also be recorded or amended AFTER the change has shipped, unlike every other content field — realised impact is often only learned once a customer explains what actually happened, and the full history is kept in the change event trail.
- reopenChange: Reopen a cancelled change — it resumes at the position (stage and state) it held when cancelled, with all stamps intact. Only cancelled changes can be reopened. Emits changeReopened.
- reportCdRunStage: Report the progress of a single stage while a CD run is in progress (one-way, best-effort ingestion from the pipeline). The stage timeline builds up during the run instead of arriving only at the terminal report. A report against an already-terminal run is ignored (the terminal report's timeline is authoritative). The app never drives the pipeline — this only records what the pipeline reports.
- setChangeStageTimes: Set or correct a change's historical stage start/finish times. Give a `stamps` array, one entry per stage `{ stage, startedAt?, finishedAt? }` (times as ISO string, epoch millis, or Date). Fills blank times OR corrects already-recorded ones. Never moves lifecycle position or current-stage state. Guards: only a stage the change has already reached may be timed; per stage startedAt <= finishedAt; no future dates; shipped records are frozen. The durable audit trail remains the stage started/finished events — this writes only the summary stamps.
- startCdRun: Report the start of a CD deployment run (one-way, best-effort ingestion from the pipeline). Creates the run in progress; as a side effect the server reconciles any prior dangling in-progress run for the team to aborted. The app never drives the pipeline — this only records what the pipeline reports.
- startChangeStage: Start work on a pipeline stage. Omit `stage` and the server resolves the next enabled stage in the product's change pipeline — callers need no workflow knowledge. An explicit stage is a deliberate jump (skip ahead, or rework an earlier stage). Records who is working (the calling actor) and the first-entry startedAt stamp; emits changeStageStarted. Optionally report `driver` — who is actually driving this stage. It cannot be derived server-side: a per-run driver override legitimately deviates from the configured pipeline, and the calling actor is the API-key identity, so an agent stage authenticates as the person whose key it holds. It is a fact report, not validated against configuration, and the first report wins. Omit it and the stage records no driver, which reads as unknown and is never inferred from configuration.
Transports
The DefProd MCP server supports both MCP transport protocols:
- SSE (Server-Sent Events) -
https://mcp.defprod.one/mcp/sse - HTTP Streaming -
https://mcp.defprod.one/mcp
Both transports provide real-time bidirectional communication between MCP clients and the MCP server. Which one you use will often depend on the capabilities of the MCP client you are using.
Authentication
All requests to the MCP server require authentication using an API key. The API key must be provided in the x-api-key header.
Users can generate API keys through their user settings in the DefProd application. Each user can create multiple API keys for different purposes.
MCP Client Configuration
To connect to the DefProd MCP server, configure your MCP client with the appropriate transport URL and authentication headers. Here are the typical configuration examples for some popular MCP clients:
SSE Transport Configuration
HTTP Streaming Transport Configuration
Replace <key> with your actual API key obtained from your DefProd user settings.
DefProd 1