One endpoint. Two products. Every tool.

claude mcp add --transport http prodready https://mcp.prodready.si/mcp --scope user

codex mcp add prodready --url https://mcp.prodready.si/mcp

{"mcpServers":{"prodready":{"url":"https://mcp.prodready.si/mcp"}}}

{"mcpServers":{"prodready":{"serverUrl":"https://mcp.prodready.si/mcp"}}}

{"mcpServers":{"prodready":{"type":"streamableHttp","url":"https://mcp.prodready.si/mcp"}}}

{"mcpServers":{"prodready":{"type":"http","url":"https://mcp.prodready.si/mcp"}}}

{"type":"mcp","server_label":"prodready","server_url":"https://mcp.prodready.si/mcp","require_approval":"never"}

npx -y mcp-remote https://mcp.prodready.si/mcp

Once it is installed you do not call the tools by name. Ask in plain language — is my app production-ready? — and your host picks them up on its own. The tool names on this page are what your agent calls, not what you type.

02Sign in

The first tool call opens a browser tab. That tab is the whole account: an email address, and nothing to remember.

1. Type your email on the sign-in page. The page is good for ten minutes.
2. Open the email. It carries a one-time link and a 6-digit code. Both are good for fifteen minutes.
3. Click the link in the same browser where the sign-in started. The link is bound to that browser, so a link someone else asked for cannot connect their app to your account. Reading the mail on another device? Type the 6-digit code into the sign-in page instead. Five wrong codes close the sign-in; start again from your host.
4. Approve the connection. The consent page shows the name the app gave itself, marked not verified, and — large — where access goes. Approve only if that is the app you just started from. Otherwise press Cancel.
5. Back in your host. It receives an access token (24 hours) and a refresh token (90 days, replaced on every use). No password, no card.

The contact record

Connecting creates a contact record at Innovate d.o.o.: your email, the time and the host name. Nothing else. The same email is the account the SDLC licence and your projects are bound to.

Revoking access

Remove the server from your host (claude mcp remove prodready in Claude Code, or the host's own settings). The host drops its tokens, and hosts that support it revoke them at /oauth/revoke. An access token already issued stops working within 24 hours; an unused refresh token is dead after 90 days. To connect again, add the server again and sign in.

Limits: five sign-in links per email per hour, thirty per network address. Past that the page says “Too many links requested. Try again in an hour.”

03The free scan

Say it in plain words:

In Claude Code you can also type /prodready:scan. Then, in order:

1. Your agent calls prodready_probe and gets back the read-only commands for your stack.
2. It runs them in your repository, on your machine.
3. It hands the counts and paths to prodready_assess.
4. You get a 0–100 score with a grade, the findings with their consequences, what could not be evaluated, and a link to the report page.

The server is remote and cannot see your disk, so it does not guess and it does not ask for your code. Nothing leaves your machine but counts, file paths and identifier names.

Then the due diligence — 18 dimensions, free

The scan is the first half of the end-to-end due diligence. The second half is the technical review our own team runs: eighteen dimensions — architecture, code quality, security posture, data architecture, infrastructure, API design, frontend, dependencies, scalability, load performance, technical debt, observability, documentation, accessibility, release management, compliance signals and cost — each scored 1 to 5 against its checklist, every finding with a file and line.

Say it in plain words:

In Claude Code: /prodready:dd. Then, in order:

1. If the scan has not run in this session, your agent runs it first.
2. It calls prodready_dd_brief per dimension and gets the rubric, the checklist with item ids and the files to read.
3. It reads the code on your machine and answers every item — a finding is an item id, a path and line, a severity and a short note. No file contents, no secrets.
4. It hands the answers to prodready_dd_assess: the server validates them (a dimension with under 60% of its checklist answered is capped at 3; load performance is scored only from load-test results you supply, otherwise it stays “not evaluated”), computes the weighted score, the risk heatmap, the compound risks and the top ten risks, and writes the report page.
5. You get the link and its access code. The page: cover with the 1–5 gauge, executive summary, critical risks, strengths, dimension scores with the weighting, top 10 risks by probability × impact, compound risks, the detail per dimension with every finding, what could not be evaluated, the method, the comparison with a prior run, and the next step. It prints to a clean PDF.

What it does not contain: remedies. The report names each gap, where it is and what it costs. Fixing it is the SDLC.

prodready_probe — the plan

Takes an optional stack (e.g. ["next","supabase","multi-tenant"]) and an optional depth:

The plan is text. It opens with the contract — the read-only command vocabulary (grep, rg, find, ls, wc, head, cat, git and their usual companions), what never to run and what never to send. Without a stack it starts with the detection commands. Then a legend, once:

Then every check: its id, severity, the rule it belongs to, the condition under which it counts as fired, and its commands. Nothing writes, nothing installs, nothing calls the network. The credential detectors never print the line a match came from.

prodready_assess — the grade

Needs evidence.results: an object keyed by check id, exactly as the plan printed it. Per check: ran, fired, count, total, files (repo-relative paths, never contents), a short evidence quote of twelve words at most, corroborated where the plan asked for it, exempt where the documented exception applies. Optional: evidence.stack, evidence.repo counts (source files, routes, endpoints, locales, very large files) and evidence.gates. report picks the delivery: link (default), html or none.

It returns:

• findings mapped to the numbered rule each one breaks, with the evidence that proves it;
• a 0–100 score built from five dimensions of 20 — data, safety, tests, review, release — with a letter grade and a Green/Amber/Red standing;
• the checks that could not be evaluated, named rather than passed over;
• the report page;
• the next step: what closing the gaps would take, and what the SDLC covers that a read-only scan cannot see.

The report page

With report: "link" the full report is stored as an unlisted page at https://mcp.prodready.si/r/<id>, in the prodready design, marked noindex, and kept for seven days. Your agent should open it for you; it is the deliverable. html returns the same page inline to save locally; none returns text and stores nothing. One account writes at most thirty report pages an hour.

Honesty rules

04SDLC on

The SDLC is our delivery process — the one our developers use to build large applications — handed to your coding agent one step at a time. It runs as a team of specialised agents: your agent builds, and the three reviewers and the sprint auditor each run as a separate agent that did not take part in building. The server hands out each step, checks the gate in front of it and keeps the ledger. It needs the licence (§07).

Story states, in order:

Gates G0–G7

There is no G1. What each gate requires is sent to your agent by the server, in the briefs, at the step where it applies. A step that skips a gate is refused with the reason and the next allowed step: “…Next allowed step: …”. Every gate result is attested: your agent reports it, and the ledger records who said so (provenance: "self-attested"). The server cannot see your disk, so it does not claim your tests really ran. It checks the order.

The sequence

1. sdlc_licence_status — is the licence active? If not, your agent offers sdlc_request_access and the free scan keeps working.
2. sdlc_project_init — creates the project and returns its id with the discovery brief. sdlc_playbook returns the brief for any step along the way.
3. sdlc_backlog_add — stories in the template's fields (see the tool reference). Stored as Draft, with what each still lacks.
4. sdlc_refine — the refinement answers per story; complete → Ready (G0).
5. sdlc_sprint_plan → sdlc_sprint_start — a goal and refined stories. Unrefined stories are refused.
6. Per story: sdlc_story_start (G2, builder brief) → build → sdlc_verify (G3) → sdlc_review_request → three reviews → sdlc_review_submit ×3 (G4) → sdlc_story_done (G6).
7. sdlc_decision_add / sdlc_decision_resolve — the decision register.
8. sdlc_audit_request → sdlc_audit_submit — the sprint audit (G5).
9. sdlc_sprint_complete — the journeys recorded (G7); the sprint closes.
10. sdlc_status / sdlc_report — the board, the gate ledger, the open decisions and the report page.

Then it iterates, sprint after sprint, until the app scores at least 4 out of 5 on the readiness scale.

Refinement (G0)

Twelve refinement questions, R1–R12. The server sends them to your agent with sdlc_playbook (topic refinement); your agent answers them per story in sdlc_refine's answers, keyed by id, with optional updates to the story's fields. sdlc_refine is also how a Blocked story is released once a person has decided what changes.

Preflight (G2) and the builder brief

sdlc_story_start runs on a Ready story in the active sprint. Preflight fails → the story stays Ready and the problems come back; close them with sdlc_refine updates and start again. Preflight passes → In Development, and the builder brief. Lost it? Call sdlc_story_start again; nothing changes, the brief comes back.

Verify (G3) — three attempts

sdlc_verify records the project's own typecheck, lint, build and tests, exactly as they came out: pass and a one-line summary each, plus counts for tests. All four pass → In QA. Otherwise one attempt is used and the story stays In Development; the third failed attempt → Blocked.

Reviews (G4) — three reviewers, three nonces

sdlc_review_request on a story In QA returns three reviewer briefs. Each reviewer runs as a separate agent in a fresh context and submits once with sdlc_review_submit.

• Nonces: one per reviewer per round, used once. A used, unknown, replaced or mismatched nonce is refused. Scores that do not match the reviewer's criteria are refused without using the nonce.
• The verdict: the server applies the reject rules from the brief to the scores and findings. A reviewer's own approve can be overruled, and the ledger says so.
• All three approve → cleared for sdlc_story_done, which records the pushed branch, tag or commit (G6). Done without G3 and G4 on record is refused.
• Any reject → the findings come back as tasks on the story, verify has to pass again, and the story returns to In Development. Rework cycles: three. The third rejected round → Blocked.

Decision register

When the work hits a business question nobody has answered, your agent records it with sdlc_decision_add: the question, who has to answer it, and how the behaviour ships meanwhile. You answer whenever you like — that rule is: … — and sdlc_decision_resolve records it with its date.

Sprint audit (G5)

When no started story in the sprint is still in flight, sdlc_audit_request returns the audit brief and sdlc_audit_submit records a 0–5 score on each of five dimensions, with findings:

An audit can block the sprint; the server tells your agent the rule. A blocked sprint is fixed and audited again.

Sprint complete (G7)

sdlc_sprint_complete takes the journeys walked — name and pass, optionally step counts and notes. All pass → the sprint is completed, and stories that did not reach Done go back to the backlog. A failing journey → the sprint stays active and the audit reopens.

Status and report

sdlc_status gives the board by state, the gate ledger summary, the open decisions and the next allowed step; call it whenever you are unsure what comes next. sdlc_report gives the project and sprint report as text and as an unlisted page on mcp.prodready.si, kept seven days.

Things to say mid-run

05Tool reference

27 tools, generated from the server's own definitions. tools/list always lists every one, licensed or not, so your host can show what exists. Licensed tool descriptions start with [SDLC licence] (left off below). Every tool rejects unknown arguments (additionalProperties: false), and every refusal carries the reason and the next allowed step. Results over 40 KB keep their head and their tail — the next step — and say the middle was left out.

06Prompts and slash commands

The server publishes eight MCP prompts. Hosts that surface prompts show them as commands; in Claude Code they are /prodready:scan, /prodready:dd, /prodready:sdlc, /prodready:status, /prodready:next, /prodready:report, /prodready:licence and /prodready:help.

Plain-language triggers

07Licence

• Sign-in is free. So is the readiness scan, and it stays free.
• The SDLC tools unlock with the licence. One licence per sign-in email; unlimited projects; the reviewer panel included; process updates for the year; the SDLC dashboard on your own computer.
• Request it by saying request the SDLC (your agent calls sdlc_request_access, optionally with a note, a company and a rough project count) or with the form on the pricing page. Your agent should ask you before it calls the tool.
• The payment link comes by email, to the address you signed in with. A person reads every request too and answers questions.
• Unlock is automatic. Once it is paid, the sdlc_* tools unlock on your account, usually within a minute. Nothing to reinstall; sdlc_licence_status shows the date it runs until.
• When it ends, the licensed tools lock again. sdlc_project_list and sdlc_project_delete keep working, so your data stays deletable.

The price: see pricing.

08Privacy & data

Deleting a project: ask your agent to delete it. It calls sdlc_project_list for the id, then sdlc_project_delete with confirm: true, which removes the document, its index entry and its report pages. It cannot be undone, and it works without a licence.

Usage is counted per day, per event and per host, without the account; analytics never receive your email or its hash. The full policy: prodready.si/privacy.

09Troubleshooting

10Protocol notes for integrators

Transport and versions

MCP over streamable HTTP at https://mcp.prodready.si/mcp. The era is chosen by method and headers, never guessed.

The server offers tools and prompts. The session id is protocol furniture, not a key into anything: the readiness tools keep no state beyond the report page.

Authorization

OAuth 2.1: authorization code with PKCE (S256), dynamic client registration, rotating refresh tokens, scope readiness. A call without a bearer token gets 401 with WWW-Authenticate pointing at the resource metadata; CORS exposes WWW-Authenticate, Mcp-Session-Id and MCP-Protocol-Version.

Other URLs

# no token needed
curl -s https://mcp.prodready.si/health
# {"status":"ok","service":"prodready","transport":"mcp-streamable-http",
#  "protocol_versions":["2026-07-28","2025-11-25","2025-06-18","2025-03-26"],
#  "tools":[…],"stateful":false,"stores_evidence":false, …}

Bounds

• A JSON-RPC batch carries at most 20 messages; a body at most 2 MB (413).
• Report pages: 30 per account an hour (per address when signed out), across prodready_assess and sdlc_report.
• Tool results are cut at 40 KB, keeping the head and the next step.
• A project document is at most 900 KB. Story fields: ≤ 8 acceptance criteria, ≤ 15 tasks, 500 characters each.
• Calls on one project run one at a time; a write that lost a race says so instead of confirming.
• Tool annotations mark readOnlyHint, destructiveHint and idempotentHint; only sdlc_project_delete is destructive.