prodready 远程 MCP 服务器是什么?
prodready 的远程 MCP 服务器是一个托管的 Model Context Protocol 端点,地址是 https://mcp.prodready.si/mcp,AI 助手无需在本地安装或运行任何东西即可连接。
prodready MCP Server已验证已精选
@Innovate d.o.o. (ProdReady)
基本信息
关于 prodready MCP Server
为你构建的应用提供免费的企业级尽职调查，由你自己的编码智能体运行：118 项只读检查加 18 个维度的评审，按 1-5 分评分并附文件和行号证据，报告页面受访问码保护。除了计数和路径，没有任何内容离开你的机器。然后说“SDLC on”，同一个服务器就会在你的项目上运行完整的交付流程：细化的待办事项、带关卡的迭代、三位独立评审、审计、自主模式，以及在你自己电脑上运行的仪表盘。
连接信息
https://mcp.prodready.si/mcp接入方式
claude mcp add prodready --transport http https://mcp.prodready.si/mcpprodready MCP Server 工具
54Free. Call it when the user asks what prodready can do, what to say, or says something you cannot map to a tool. Pass what they said in `said` (optional). Returns the flows this server offers, the plain phrases that start each, which tools they use, and — if `said` matched — the one flow to run now. No data leaves the machine.
Step one of a production-readiness and security review of the user's own codebase. Reach for this whenever someone asks whether the app they built is ready for real users, safe to launch, secure, safe to put customer data in, multi-tenant safe, or whether it will hold up when it gets traffic — and whenever they want a second opinion on something a coding tool generated for them. This server is remote and cannot see the user's disk, so it does not guess and it does not ask for the code. It returns the exact read-only shell commands and file globs to run locally: one per detector in the prodready hardening catalogue — 25 numbered platform rules across wiring, configuration, multi-tenant isolation and row-level security, UI and internationalisation, operations, and compliance and lifecycle, plus the critical-rules set covering data integrity, API surface, state machines, auth and sessions, secrets, logging and tests. Every command is read-only — grep and rg, find, ls, wc, head, cat, git, and their usual companions awk, sort and xargs. Nothing writes, nothing installs, and nothing a command does calls the network. Four checks carry a read-only query against the database's own catalogue; the plan marks those SQL> instead of $, they run only against a connection the user hands you, and no check depends on one. The credential detectors never print the line a match came from, so no secret value is read or sent. By default the plan is every scoring probe plus the critical and high-severity detectors — the ones that decide whether the app is safe to put real users on. Pass depth:"full" for the whole catalogue, or depth:"stack" for just the commands that work out what the app is built on. Run the steps, then hand what came back to prodready_assess for the graded report.
Step two: turn what prodready_probe's commands returned into a graded readiness report. Gives back: 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; a link to the full report page in the prodready design (open it for the user — it is the deliverable, unlisted, kept seven days); and the next step: what closing the gaps would take, and what our SDLC covers that a scan cannot see. The scan is free. Each finding names the gap and the consequence of leaving it in. It does not name the remedy: the diagnosis is free, the fix is the product. Do not ask this tool for a patch, a policy, a migration or a config — it has none to give, and it will not invent one. Evidence is used for this one call and is never stored and never logged. Send counts, file paths and identifier names. Never send the contents of a .env, a key file, or any matched secret value.
Free. Step one of the 18-dimension technical due diligence of the user's own codebase — the deep review behind 'due diligence', 'deep review', 'audit the architecture'. Run prodready_probe and prodready_assess first if they have not run in this session (the end-to-end due diligence is both). Returns which dimensions apply to this stack and, for one dimension (or every applicable one when `dimension` is omitted — large), its 1-5 rubric, its checklist with item ids, the files and areas to read, and the exact JSON shape to hand back to prodready_dd_assess. Read-only; nothing is stored. You read the code on this machine. Never send file contents, environment values or secrets: a finding is a checklist item id, a repository path (and line), a severity and a paraphrase of at most 200 characters naming the gap and its consequence — not a fix.
Free. Step two of the 18-dimension due diligence: hand back what you established per dimension with prodready_dd_brief. Validates it (unknown ids, scores outside 1-5, findings without a path are refused; a dimension with under 60% of its checklist answered is capped at 3 and marked partial; performance-load is scored only from load-test results you supply, otherwise it is 'not evaluated', never 1), then computes the weighted 1-5 score and grade, per-dimension risk (probability x impact), the 5x5 risk heatmap, compound risks across dimensions, the top findings and what could not be evaluated, and leaves a report page (link + six-character access code, seven days). Open the page for the user and give them the code. The report names each gap, where it is and what it costs. It does not name the remedy and refuses fields that would carry one.
Whether the signed-in account holds the prodready SDLC licence, until when, where to unlock it, and what it contains. Free, and works before the licence is paid. Call it when an sdlc_* tool refuses, or when the user asks what the SDLC is.
Asks for the prodready SDLC licence for the signed-in account. The payment link is emailed to that address automatically; the sdlc_* tools unlock on this account the moment it is paid. Free. Call it when the user wants the SDLC after sdlc_licence_status or a refusal, never on their behalf without asking them first.
[SDLC licence] Creates a project on the user's account and returns its id with the discovery brief: what to establish about the product before any story is written. Start here for a new app, a rebuild, or when the user wants their project run through our delivery process. Pass brownfield: true for an app that already exists.
The projects on this account, with their ids. Works without an active licence, so a lapsed account can still find what to delete.
[SDLC licence] The structured brief for one part of our delivery process: how stories are written, refined, estimated, built, reviewed and audited, the gates between them, and how open business decisions ship. Read the relevant brief before doing that step.
[SDLC licence] Stores user stories on a project. Each is checked against the story template and stored as Draft; what it still lacks is listed. Routes that collide with another story's, or that are missing from the UI contract, are refused. Read sdlc_playbook story_writing first; for a whole backlog use sdlc_backlog_import.
[SDLC licence] Records the answers to the refinement checklist for one story, with optional field updates. When every item is answered and the story fits the template, it becomes Ready (gate G0); otherwise the open items come back. Also how a Blocked story is released after a person has re-scoped it. v2: reasoning and sources per checklist id, selections (the question set of the round: options, default, pick, why), decisions (business questions filed with the story; it may still become Ready and ships the behaviour switched off), paused (a question nobody can answer from the sources: the story stays Draft and a blocking question is filed). Inside an autonomous session every answer needs its own reasoning (20+ characters), selections are required, blanket reasons are refused, and a third failed round pauses the story.
[SDLC licence] Creates a sprint with one business goal and the refined stories that deliver it, or — with sprint_id — promotes an outlined sprint from the imported backlog once its stories are refined. Stories that have not passed refinement are refused.
[SDLC licence] Makes a planned sprint the active one and returns the sprint brief: the goal, the stories in build order and the cycle to follow.
[SDLC licence] Runs the preflight check (G2) on a story in the active sprint and, when it passes, moves it to In Development and returns the builder brief: execution rules, coding standards, the definition of done and the story itself.
[SDLC licence] Records the results of the project's own typecheck, lint, build and tests for a story in development, exactly as they came out. All four pass: the story moves to In QA (gate G3). A failure counts as one attempt; the third failed attempt blocks the story.
[SDLC licence] For a verified story: returns three reviewer briefs — architecture, security, functional — each with its own one-time nonce. Run each review in a fresh context (a separate sub-agent with no memory of the build), then submit each with sdlc_review_submit.
[SDLC licence] Records one reviewer's scores, findings and verdict, using the nonce issued to that reviewer for that story. When all three are in, the story is either cleared for Done (G4) or sent back to development with every finding as a task.
[SDLC licence] Marks a story Done once verify (G3) and the three-reviewer approval (G4) are on record, and records the pushed branch or commit (G6).
[SDLC licence] Adds a row to the decision register. kind business (default): a business question nobody has answered yet, who must answer it, and how the behaviour ships until then (switched off, or a conservative default). kind question: an open question with its urgency and the agent's best assumption. kind assumption: something the agent assumed, with its reasoning and confidence. Technical choices belong in the architecture document (sdlc_design_set), not here. Returns the register.
[SDLC licence] Records the answer to an open row with its date and returns the register. by owner (default) is the owner's own answer — pass their words in owner_words; by agent may only assume a non-blocking question. override: true changes a decided row by appending a new row. Stories built on a changed answer are re-opened or get a task, and the result lists them.
[SDLC licence] When no story in the active sprint is still in flight: returns the audit brief — five dimensions, what to check in each, and when the audit blocks.
[SDLC licence] Records the audit's five scores (0-5) and findings. Any dimension at 1 or below, or any critical finding, blocks the sprint until the findings are fixed and the audit is run again.
[SDLC licence] Completes an audited delivery sprint and records the critical user journeys walked end to end (G7), the merge (G6, scope sprint) and readiness after the sprint (G8: the sprint's recorded due-diligence and load-test runs; score 3 or more passes, 4 meets the target). Stories that did not reach Done return to the backlog; the retrospective follows (sdlc_sprint_retro). A hardening or hotfix sprint completes when every story is Done or escalated and a clean sdlc_bug_detect on it is newer than its last Done. The user says: 'complete the sprint', 'close the sprint', 'finish sprint 2', 'merge the sprint', 'zaključi sprint'.
[SDLC licence] Autonomous refinement: start opens a refinement session over the Draft stories of the backlog (or one sprint) and returns the brief for the first story — the checklist, the sources to read and the rule: answer from the sources; a real business question becomes a decision, never a question to the user. submit applies sdlc_refine v2 per story (≤ 5 per call; reasoning per answer, selections, decisions, paused) and returns the next brief; status lists the queue, the results and the open decisions ("answer D-n: <your answer>"); finish closes the session with the report { refined, paused, decisions_raised }. start needs the person's own go-ahead in authorised_words (for example 'refine the backlog on autopilot') unless an autonomous session is active.
[SDLC licence] Autonomous work. start opens a session (limits: stories, sprints, minutes; defaults 1 sprint and 240 minutes) — it needs the person's go-ahead in their own words (authorised_words, e.g. 'run it unattended for one sprint'). status returns the ONE next step of the loop: do exactly that step, then call status again; it pauses with needs_human when a blocking question or a Blocked story needs a person, stops at a limit, and lists the questions (blocking, pending with when each is assumed, assumed) — show them to the user every cycle and keep working. pause, resume, stop ('SDLC off') and compact manage the session; pause and stop work without a licence.
[SDLC licence] Discovery: what the product is, for whom, and what the first release holds, scored per knowledge area (0-100 in all). start: send the kinds and labels of the documents that exist here (never their contents), brownfield, and the scan or due-diligence score when there is one; returns the discovery plan (mode, round budget, areas, round 1's business questions, the rules). round: after reading and asking, send each area's score (0-20) and a short summary (counts and names only), the assumptions made, the questions still open (a non-blocking one carries its assumption), answers the owner gave, risks and contradictions; returns the knowledge score, the gaps and the next round. finish: at 80 or more, the first-release line, the features with priority and whether each has rough acceptance criteria; records gate GD (pass or fail). Read sdlc_playbook discovery first. The user says: 'discovery', 'gather requirements', 'interview me', 'here are my docs', 'next round', 'what's missing', 'finish discovery'.
[SDLC licence] The scope baseline: the objective, what is in and out of scope, assumptions, integrations and the architecture in a line each. A field sent replaces that list; a field left out is kept. Returns the scope and what is still missing before a statement of work can be issued. The user says: 'record the scope', 'this is in scope / out of scope', 'what did we agree is not included'.
[SDLC licence] Issues a new version of the statement of work from the recorded scope, backlog, sprints, risks and architecture: summary, scope, solution, sprint plan, deliverables, effort in points (no hours, no money), risks, acceptance (gates by name), timeline. format page (default) writes a report page and returns REPORT PAGE and ACCESS CODE — give the user both; format text returns the text only. The version is draft while a story is unsized or Draft, or the first-release line is only assumed. Needs the scope (sdlc_scope_set) and at least one story. The user says: 'statement of work', 'SoW', 'proposal', 'give me something to sign off', 're-issue the SoW'.
[SDLC licence] The product vision in business language: 2-5 user journeys (steps that point at modules), 4-8 modules each with 2-5 features (features point at the stories that build them), and the connections between modules. Status is never sent: each feature is built / in progress / planned from its stories on every read. The server checks every reference, refuses paths and code in names, and returns the diff against the stored version and the gaps (features without stories, modules no journey uses). Read sdlc_playbook vision first. The user says: 'product vision', 'what are we building', 'feature map', 'refresh the vision'.
[SDLC licence] The user journeys as screens and links: personas, screens (persona, route, the features it serves, its wireframe page), links between screens, and the critical journeys that are walked before a sprint completes. The server binds stories to screens and returns coverage per screen and the gaps (screens without stories, interface stories without a screen, links to unknown screens). Read sdlc_playbook journeys first. The user says: 'user journeys', 'user flows', 'storyflow', 'map the journeys'.
[SDLC licence] Records the wireframes drawn in this repository (paths only, never images): the design tokens by name, the navigation per persona, every page with its persona, file under .prodready/wireframes/, features and states, and the clickable prototype. Returns what is missing (vision features without a page, pages without all four states) and, unless assign is false, gives interface stories without a design reference the page that shows them. Read sdlc_playbook wireframes and follow it first. The user says: 'wireframes', 'mock-ups', 'clickable prototype', 'design the screens'.
[SDLC licence] The architecture document: a summary, up to eight standard sections (system architecture, data flow, entities, state machines, interface structure, security, deployment, integrations), each with an optional diagram as mermaid, plantuml or dot text, the decision records (context, decision, alternatives, consequences) and architectural improvements. A section sent replaces that section; records and improvements patch by id; an improvement with to_backlog becomes a Draft story. Code is refused anywhere but a diagram's source. Returns the sections present and missing, the records, the gaps and the diff. Read sdlc_playbook design first. The user says: 'architecture document', 'SDD', 'system design', 'architecture decisions', 'ADR'.
[SDLC licence] Records documentation produced by a generator in this repository (interface reference, schema, components, architecture, setup): the output path, the generator's path, when it ran and how many items it covered. Documentation here is produced by software that can run again, never written by hand: an entry without a generator is refused, and a generator that is not idempotent or not timestamped is listed as an open item. One entry per type; a new one replaces it. Read sdlc_playbook generate_docs first. The user says: 'generate the docs', 'documentation', 'API docs', 'regenerate the docs'.
[SDLC licence] Files one bug as a bug story ("Fix: …") with its severity, repro steps, expected and actual behaviour. With its evidence (error_summary, location path:line and category) and outside an active delivery sprint it is refined by the bug template (G0) and lands Ready; otherwise it lands Draft and is refined like any story. A report matching an open bug's check and location is attached to it. next fix_now (critical/high) leads to sdlc_hotfix_start. The user says: 'report a bug', 'there's a bug', 'this is broken', 'prijavi bug'.
[SDLC licence] Records a whole-suite sweep — typecheck, lint, build, tests and e2e as your agent ran them — and triages every failure into a proposed bug (build critical; typecheck and tests high; lint medium), grouped by area, deduplicated, with the hardening cycle (n of 3). Recorded as gate G3 with scope sprint (never a story's verify failure). Clean → the next step; failures → sdlc_sprint_harden; at cycle 3 the remaining bug stories are Blocked for a person. The user says: 'find bugs', 'what's broken?', 'is everything green?', 'bug sweep', 're-test'.
[SDLC licence] Opens a hardening sprint — restore a green suite, no new features — from a failing sdlc_bug_detect (detection_id, with the bug stories to fix, or the detection's own failures when stories is omitted) or from queued bugs (bug_ids). Bug stories from a detection are refined by the bug template (G0). Returns the hardening brief and the first story by severity. Cycle budget 3. The user says: 'harden it', 'hardening sprint', 'fix what's broken', 'make the build green', 'fix the queued bugs'.
[SDLC licence] The fast track for a critical or high bug: a hotfix sprint beside any active delivery sprint, holding one bug story marked hotfix. Preflight (G2), verify (G3, three attempts), the three reviews (G4, no shortcut) and push (G6) stay mandatory; then sdlc_bug_detect on the hotfix sprint and sdlc_sprint_complete. Pass story_id (an existing refined bug story) or bug (the sdlc_bug_report fields, with its evidence). The user says: 'hotfix', 'production is down', 'urgent fix', 'P0', 'SEV1', 'hitno popravi'.
[SDLC licence] Records k6-style load-test results (aggregate, per route, capacity): scored 1–5 with the due diligence's load-test bands, pass or fail against the thresholds (p95 800 ms, 5% errors by default), and a verdict against the previous run of the same profile. A run with sprint_id is that sprint's readiness load test (G8). Credentials only from environment variables; target_label is an environment name or bare host. Inside an unattended session only smoke runs, unless limits.perf names the profile and target. The user says: 'load test', 'performance test', 'how fast is it', 'capacity', 'run k6'.
[SDLC licence] Records the monitoring checklist (M-01…M-10: yes, no or n/a), the monitored targets and production incidents. Scores the monitoring, flags "armed but blind" when no target was seen in 24 hours, turns a SEV1 with its evidence into a critical bug story (next sdlc_hotfix_start) and reminds you of missing postmortems. The same incident twice within 15 minutes is refused. The user says: 'monitoring', 'alerts', 'is it monitored', 'incident', 'postmortem', 'uptime', 'on-call', 'nadzor'.
[SDLC licence] Records a due-diligence run on this project — the fields from prodready_dd_assess (and optionally prodready_assess) — as DD-n: overall, grade, dimension scores, findings by severity and the top risks, never remedies. With the report_id of this account's due-diligence page from the last seven days the figures are taken from the server's own summary (server-scored); otherwise the run is self-attested. Updates the readiness and its trend toward the target of 4 out of 5. The user says: 'record the due diligence on the project', 'due-diligence trend', 'are we at 4 out of 5'.
[SDLC licence] The retrospective of a completed sprint: what went well, what to improve, what was blocked and why, and actual hours or points per story. The server tabulates estimates against actuals, stores the recalibration factor and says when sizes run outside the estimation bounds. The next delivery sprint does not start until the previous one has its retro. The user says: 'retro', 'retrospective', 'what did we deliver', 'what went wrong this sprint', 'retrospektiva'.
[SDLC licence] Adds or updates risks (with id: update). Scores probability × impact into bands (20–25 critical, 12–19 high, 6–11 medium, 1–5 low), flags duplicates by title, returns the sprint risk profile and buffer (10/20/30%) and which critical risks hold sdlc_sprint_start. A vague mitigation ('monitor', 'tbd', under 10 characters) is refused; accepting a risk needs a rationale and files a decision; spike: true drafts a spike story. The user says: 'risks', 'risk register', 'what could go wrong', 'add a risk', 'we accept that risk', 'rizici'.
[SDLC licence] A computed prediction (no model call): five dimensions × 20 — requirements clarity, technical feasibility, scope control, risk profile, delivery confidence — from your evidence plus what the project already records (stories, open questions, risks, the latest due diligence, verify and rework history). Grade A–F with RAG, hard caps and the delta against the last prediction. A grade F holds sdlc_sprint_start. The user says: 'will this succeed', 'success prediction', 'what are our chances', 're-score', 'hoće li uspjeti'.
[SDLC licence] The UI contract: route registry (path, screen, layout, nav group), navigation, layouts, shared components and token rules. Versioned; merged into the stored contract unless replace is true. Refuses duplicate or near-duplicate paths and nav entries to unknown routes; reports violations by stored stories (routes outside the registry, near-duplicates, orphan routes). Stories are then checked against it. The user says: 'UI contract', 'route registry', 'lock the routes', 'shared components', 'UI ugovor'.
[SDLC licence] The whole backlog in one validated, atomic write: sprints (outlined, with goal, theme, outcomes and their stories) plus unassigned stories, and optionally the UI contract. depends_on may name a story of the same call as "#<n>" (1-based across the call). ≤ 60 stories. Checks route uniqueness and the contract, and the structure (foundation first, 3–8 stories per sprint, ≤ 5 points, a build-and-deploy check story per sprint). dry_run: true returns the same and stores nothing — show it to the user first. Any refusal stores nothing. Read sdlc_playbook backlog first. The user says: 'create the backlog', 'write the backlog', 'turn the requirements into stories', 'import my backlog', 'napravi backlog'.
[SDLC licence] The board by state, the gate ledger summary, open decisions and questions, discovery, risks and documents, and the next allowed step. Call it whenever you are unsure what comes next. With story_id it prints that one story in full — how a builder, reviewer or auditor fetches a story a brief listed by id.
[SDLC licence] The project and sprint report as text, plus an unlisted page on mcp.prodready.si in the prodready design, kept for seven days. Open it for the user and give them the link.
[SDLC licence] The whole project as one self-contained HTML file for the user's own computer: board, backlog, sprints, gate ledger, reviews, decisions, audits, timeline, cost and report pages. Save the attached file as .prodready/dashboard.html in the repository and open it in the browser; call this again after each step to refresh it. Nothing is stored on the server. format "summary" returns the counts as text only.
The project document as JSON for the local dashboard (`npx https://prodready.si/dl/prodready-dashboard.tgz`), which reads it and renders every page on the user's own computer. Read-only; nothing is stored. No nonce, write token or email address is included. With a licence it also carries the spec labels and the derived views (next step, counts); without one it still returns your own project data. Pass if_version (the version you already hold) to get { unchanged: true } instead of the document when nothing changed.
Deletes the project document, its index entry and its report pages. Cannot be undone. Works without an active licence: your data stays deletable after the licence ends.
[SDLC licence] Read-only metrics computed from the project: per sprint the stories total / Done / Blocked / carried over, completion, points planned and done (velocity), verify failures (story G3 rows only), rework cycles, the review rejection rate, audit rounds, cycle time (median, p90), estimate accuracy from the retro, gate pass/fail counts, bottlenecks (top 5), retry root causes, per owner, tokens where the host reported them, the readiness trend and — with compare — the trend between sprints with neutral signals. Nothing is stored; the recommendations are yours, written into sdlc_sprint_retro improve. The user says: 'sprint analytics', 'velocity', 'how fast are we', 'burndown', 'how did the sprint go', 'bottlenecks', 'compare sprints', 'analitika'.
[SDLC licence] plan: a release (REL-n) of completed sprints with a derived changelog — Done stories by type, fixed bugs, decisions that ship switched off as known limitations, implemented change requests. Refused for a sprint that is not completed, already in a live release, or holding an open blocking question. advance: planned → staging (deployed to a non-production environment with a passing smoke check) → ready (rollback plan and a readiness score of 3 or more on record) → released (approved_by a role, merge_commit and a production deployment with a passing smoke check). rollback: released → rolled_back with a reason. Releasing and rolling back are a person's steps. Environment labels are names only — no URL, host or credentials. The user says: 'release', 'cut a release', 'ship version 1.2', 'ship it', 'deploy to staging', 'changelog', 'release notes', 'roll back', 'izdanje'.
[SDLC licence] submit: a change to the agreed scope (CR-nnn) — stories to add, modify or remove — with its impact computed: points added / removed / changed, stories and sprints affected, whether the active sprint is touched, the delta against the statement of work. At most 5 open at a time. decide (a person's step, reviewed_by a role): approved adds the new stories as Draft (origin change_request), applies the changes (the story is refined again), removes stories that have not started, and marks the SoW stale; rejected or deferred changes nothing. A story in flight or Done is not modified or removed (a Done story changes through a new story). The user says: 'change request', 'the client wants …', 'scope change', 'add this to the scope', 'drop that feature', 'zahtjev za promjenu'.
概览
What is prodready?
prodready is a remote MCP server that answers one question for the app you built — in Lovable, Replit, Base44, Bolt, v0, Cursor or Claude Code: is it production-ready?
Your own coding agent runs the checks on your machine. Nothing leaves it but counts and paths.
What you get for free
- 118 read-only checks across five areas: data, safety, tests, review, release — a 0–100 score and a grade.
- An 18-dimension technical due diligence — architecture, security, data, code quality, testing, compliance and twelve more — each scored 1–5 with file-and-line evidence, a risk heatmap and the top risks by probability × impact.
- A report page in the prodready design, protected by an access code your agent prints next to the link. Kept 7 days, results only.
The free tier names every gap and what it costs you. It does not prescribe the fix.
Then: "SDLC on"
With a licence, the same server runs a full delivery process on your project: discovery, product vision, SDD, a refined backlog, gated sprints, verify, three independent reviewers on every change, audits, due diligence and load tests after every sprint — until the app scores 4 out of 5. Autonomous mode keeps going on its own and only stops for questions only you can answer. A dashboard runs on your own computer.
Install
- Claude Code:
claude mcp add --transport http prodready https://mcp.prodready.si/mcp --scope user - Codex CLI:
codex mcp add prodready --url https://mcp.prodready.si/mcp - Cursor / Windsurf / Cline: add
https://mcp.prodready.si/mcpas a remote server (ornpx -y mcp-remote https://mcp.prodready.si/mcp) - Claude Desktop / claude.ai: Settings → Connectors → Add custom connector →
https://mcp.prodready.si/mcp
Sign in with your email (magic link). Then ask: is my app production-ready? — or say due diligence.
Links
- Website: https://prodready.si/
- Docs: https://prodready.si/docs/
- How the SDLC works: https://prodready.si/sdlc/
We listen, and we do not judge.
常见问题
怎么连接 prodready 的 MCP 服务器?
把端点 https://mcp.prodready.si/mcp 添加到任意支持 MCP 的客户端,比如 Claude Code、Cursor 或 VS Code。本页的接入代码块可以一步配置好每个客户端。
prodready 的 MCP 服务器需要认证吗?
需要。prodready 使用 OAuth——第一次连接时,你的 MCP 客户端会打开浏览器窗口登录并授权,之后会复用这个凭证。
prodready 的 MCP 服务器用的是哪种传输方式?
prodready 暴露的是 Streamable HTTP 端点,这是远程 MCP 服务器普遍使用、主流客户端都支持的传输方式。
更多远程 MCP 服务器
Aard
Aard connects Macroeconomic and other official data from 170+ publishers including World Bank, IMF, BIS, ECB, Eurostat, and National Statistical Offices. Aard is powered by a large graph of the metadata universe and an
AWS Marketplace
Discover, evaluate, and buy solutions for the cloud
1
1cent
Production remote MCP server with 35 safe web-intelligence tools: 32 paid x402 URL operations plus 3 free discovery/demo tools. Base Mainnet USDC, no account or API key; SSRF protection, strict schemas and idempotent set
A
AIS Gateway
CVE prioritization using exploitation signals, plus agent heartbeat monitoring and state capsules. Some tools use API-key or x402 access.
A
Aayat AI
Pay-per-use data and tools for AI agents: crypto token safety and rug checks, web search with cited answers, page-to-Markdown, up-to-date library docs, package safety, company research and UK/EU open data. 160 tools, 20
评论