CorPole MCP Server

Endpoint

Hosted endpoint · transport

Connect

This is a remote MCP server — point an MCP client at the endpoint URL. Clients with native remote support (Claude, Cursor, VS Code, …):

For stdio-only clients (older Claude Desktop, etc.), bridge with mcp-remote:

If the server requires authentication, add the provider's token/header (e.g. an X-API-Key) per its docs. A quick reachability check:

Tools

• get_authority_context — Every Authority record of the solution, grouped by type, with its acceptance criteria and their status, plus the agent instruction.
• search_requirements — Keyword search in title, code, statement and acceptance criteria.
• get_record — Full detail of one record: state, statement, rationale, each acceptance criterion with its code (e.g.
• get_work_context — The context slice for one record or work item: acceptance criteria, the why-chain, realizing technical requirements, dependencies, constraints (linked and solution-wide), technical requirements that realize no requirement (the closest in wording with their statement), open conflicts, replacements; f
• list_work_items — Themes, epics, work packages, stories, tasks and subtasks with status, parent and the requirements they implement, e.g.
• update_work_status — Moves a work item along its workflow: stories to In progress or Code review, tasks to In progress or Check, subtasks to Doing or Done.
• get_standards — Standards that apply to the solution (tenant-wide and solution; waived ones listed separately), with must/should enforcement.
• search_knowledge — Search decisions, questions, glossary terms, standards and references.
• ask_question — Records an open question with the working assumption, linked to what it concerns.
• propose_decision — Proposes a decision the agent itself makes within what it may decide (an architecture or design choice, ADR); binding only once a person accepts it.
• propose_relation — Proposes a typed relation (refines, realizes, constrains, replaces, conflicts_with, relates_to).
• create_project — Creates a solution for the user in their workspace and switches an OAuth connection to it.
• get_setup_brief — The kickoff interview for a new solution: interview rules, the steps with why and an example, what exists so far and what comes next.
• submit_setup_records — Stores one confirmed kickoff section: solution brief, Draft records with criteria and links, open questions.
• propose_change — Proposes a change to an existing record.
• get_package_brief — The shared work package, masked: what to do, criteria and how they are checked, constraints, standards, agent policy.
• get_regression_candidates — The tests to run again after what changed since a date (changed requirements, finished work, changed design records), riskiest first with the reasons; quarantined tests left out.
• propose_test_set — Keeps a regression set of the solution or a UAT session of an initiative (filled with its criteria with from_initiative).
• get_test_set — A test set's items in order with roles and results so far, and its outcome once closed.
• report_test_set_result — Records the result of a test item of a set, also as a run of the test.
• get_test_history — Recent runs of a test and whether it is passing, failing, regressed or flaky; the same for every test of a criterion; or the solution's flaky and quarantined tests.
• quarantine_test — Quarantines a flaky test until it is fixed, or releases it.
• propose_bulk_change — Proposes the same change to many records with one reason, e.g.
• get_change_batch — A bulk change proposal: its reason and source, and whether each record's change is open, accepted, rejected or superseded.
• propose_work_items — Proposes epics, stories, tasks and subtasks into the Backlog.
• get_handover_brief — The solution's authority tier (Shadow, Shared, Full) and how to move agent rule files, requirement documents and ADRs into CorPole as proposals.
• declare_emergency — Opens a time-boxed production emergency when a person allowed to declare one says so: code gates advise instead of refusing, forbidden actions stay forbidden, a defect tracks it.
• get_repo_kit — Files that make a code repository treat CorPole as its requirements authority (the CorPole block in CLAUDE.md and AGENTS.md, pointer files for Gemini, Copilot and Cursor, team plugin settings, and the provider's change-request template and CI check: GitHub PR template and Actions, or GitLab merge re
• propose_record — Adds a Draft marked as an AI proposal, with its acceptance criteria as separate items.
• report_acceptance_result — Records whether one acceptance criterion is met, with evidence.
• get_agent_policy — What agents may do on their own, only after asking, or never (migrations, dependencies, CI/CD, merging, deploying, production data…), and the agent rules in force for this person.
• get_changes — What changed since a moment: records, criteria, relations, work items, knowledge, tests and code links, with who, the field changes and the reason.
• check_code_area — Before changing files: whether they are governed.
• get_onboarding_brief — How to bring an existing codebase under governance: the discovery protocol, the source trust order, the current modules and the maturity.
• submit_onboarding_findings — Submits what was found in an existing codebase in one batch.
• leave_handover_note — Leaves a note on an unfinished work item for whoever continues it: what is done, what is open, the next step.
• link_code — Attaches a pull request, commit, branch, file or CI run to a story, task or record.
• propose_test_case — Registers a test that proves acceptance criteria.
• report_test_result — Reports one test run: passed, failed or blocked.
• report_defect — Records behaviour that breaks a requirement or criterion.
• raise_risk — Records a risk in the register.
• submit_retrospective — Records lessons learned and improvement ideas.
• submit_handover_inventory — Records the sources that govern the solution outside CorPole (agent rule files, requirement documents, ADRs, glossaries, tickets) with their size and status: to move, moved, historical or staying outside.
• proceed_without_kickoff — For a new solution without Authority records: records that the user chose to build without the kickoff interview, with the reason.
• propose_rule — Proposes behavioural rules for agents on this solution — from an agent rule file, a recurring lesson or the conversation — as Draft solution rules.
• select_initiative — Chooses the open initiative this session's new work and requirements go to (12 hours); without a code it lists the open initiatives and the current choice.
• switch_solution — The same as switch_project, named for the delivery model: moves an OAuth connection to another solution.
• switch_project — Moves an OAuth connection to another solution the user can open; every switch is written to both solutions' history.
• what_do_we_have — Does the solution have it: matching requirements with their state, whether work built them and tests prove them, related decisions, lessons and questions, and work that mentions it without a requirement.
• explain_change — Why something exists: the requirement it serves and the chain above, who asked and approved, decisions behind it, and the reasons agents gave when linking the code.
• check_readiness — Ready / Not ready for a work item or record, criterion by criterion: met, tested, failing tests, open defects, tests older than the criterion, open questions, conflicts, vague wording.
• review_requirements — Quality and coverage scan: vague wording with no question, missing criteria, binding criteria with no test, conflicts, likely duplicates.
• review_test_fit — Each criterion next to its tests with steps and automation, and warnings for stale, loosened or often skipped tests — for the agent to judge.
• report_test_fit — Records the agent's verdict on a criterion ↔ test pair in the test's history; a poor fit reaches the people who verify criteria.
• get_conformance_checklist — What the code must conform to: binding constraints, non-functional and technical requirements, active standards — narrowed to a path's module.
• report_conformance — Records a conformance review's table in the solution history; deviations reach the integrations owners.
• get_impact — What a change to a record reaches: open work that implements it or covers its criteria, the tests of its criteria, open pull requests of the record or that work, and the records that refine, realize or depend on it.
• persist_instruction — Keeps what should bind others in the solution: a Draft solution rule, constraint, standard or glossary term for approval.
• set_working_mode — Switches a ready-made working mode on or off — plan first, small steps, analysis only, tests first, smallest change, challenge me — for the person at once, or as a Draft solution rule.
• get_decision_queue — What waits for the person's decision in the solution, by their permissions: agent drafts, change proposals, proposed decisions, open questions, proposed solution rules — with content, proposer and age.
• prepare_decisions — Stores the agent's short summary and recommendation per waiting item for the person's "Waiting for you" screen, where the person decides in one pass.
• answer_question — Passes on the person's answer to an open question.
• record_decision — With kind direction: records a direction — which way the work goes from now on — as the person's sentence, word for word (at most 600 characters; no context, governs_codes or priorities), with the scope this solution; the agent does not ask about making it permanent.
• get_my_overview — Every solution the person can read, each in its own section: work in progress for them, decisions waiting, dates due in two weeks, maturity below target, serious issues; then the next two weeks across solutions.
• get_portfolio — Old name of get_my_overview, kept as an alias.
• get_status — For a person's own connection it lists the directions in force (code and sentence, newest first), or says none is in force.
• get_maturity — Where the solution stands on seven dimensions (intent, requirements, verification, delivery, agent governance, codebase, decisions and knowledge) against its target profile, with at most three next steps.
• approve_records — Moves records to Approved only after the user confirms in their AI client (MCP 2026-07-28 elicitation), with the user's own permissions and the board's checks.
• get_audit_trail — Changes and agent calls of a closed period in one timeline; exists answers yes or no with the first and last time, summary gives the period's security counts; every answer says what it rests on.
• get_access_review — Members, solution access and agent credentials with unused, open-ended and orphaned ones flagged; for one person, what breaks when they leave.
• record_access_review — Records that an access review was done, with the outcome and the counts of that moment, in the history and the audit trail.
• get_compliance_matrix — Standards and binding requirements down to records, criteria, tests, results and exemptions, each Proven, Failing, Not run, No test, No criterion, Exempt…; for an audit period only runs within it prove a criterion.
• get_time_report — Agent session time by Türkiye day and solution: engaged, working, waiting and idle time, touched codes and finished work for you; day totals without names for the solution.
• take_baseline — Names this moment and freezes records, criteria, work, tests, decisions and key numbers, to compare against later.
• compare_baseline — What changed since a baseline (or between two): records, criteria, work, tests and decisions added, removed or changed, and the numbers then and now; lists baselines without arguments.
• assess_request — Splits a request into its asks and compares each with the solution (New, Already there, Partly there, Retired before, May conflict), and records it as a demand in the Funnel with the assessment kept on it; received_at keeps the day it came in, and the answer names similar open demands.
• list_design_records — The solution's design today by kind (BDR, FDR, NFDR, TDR, ADR), with version, drafts to confirm and pending changes.
• get_design_record — One design record: description, acceptance, versions with the work, requirements and initiative behind each, and pending changes.
• propose_design_delta — Records the design change an open work item carries (add, change, retire); applied as a new version when the work is Done.
• get_flow_metrics — Flow time of demands and initiatives (median, 85%), flow efficiency, load per step against WIP limits, distribution by capacity type, velocity per week, and the step where work waits longest.
• get_defect_trail — What a defect violates, its tests' last pass and first failure, and the recent changes that most likely caused it, ranked with reasons.
• get_release_notes — What an initiative delivered: demands answered, design changes, delivered work, fixed defects, known limitations.
• get_evidence_pack — The proof behind an initiative: requirements, criteria, tests and latest results, approvals, design changes with provenance, change requests with CI and reviews, what is still open.
• get_portfolio_board — The Lean Portfolio Kanban: unlinked demands, initiatives by step with mode, stage, days in step, work finished/total, solutions and demands; WIP limits.
• get_initiative — One initiative: mode, step, capacity, demands, solutions, work with open items, and the steps it may move to (Done only when all its work is closed).
• list_demands — The workspace's demands with step, days in the step and linked initiatives.
• get_demand — One demand: request, requester, channel, step, initiatives and the solutions they change, kept assessment.
• check_planning — Which candidate items would pass the Ready gate and what each still lacks (requirement and criteria, triage, description, dependencies, blocks, open questions), and the active and Ready load per person and agent.
• preview_governance_change — What a gate, agent permission or code rule change would do before it is made: refused or freed moves and calls of the last 30 days, items stopped today, solutions whose level changes.
• get_my_signals — The connection's own open drift signals with why each matters, and the solution's accepted lessons.
• get_project_tour — A tour for someone new: problem and objectives, binding decisions and standards, agent rules, glossary, open questions, where the work is, who is in it.
• get_metrics — MET-01…10 of the solution with targets and what each counts.
• track_requests — What came from one person, unit or customer and where it stands: records requested by them with build and test state, decisions they took, records they own or that mention them, questions and work naming them.
• get_forecast — When the remaining work of the solution or one item with everything under it is likely done (50% and 85%), the chance of a target date, what slows it down, a pull-forward what-if and due dates against actual finish.

About MCP

The Model Context Protocol (MCP) is an open protocol Anthropic introduced for connecting LLM-based agents to external tools and data sources. Providers publish MCP servers that expose their API surface as structured, discoverable tools — an MCP-compatible client (Claude Desktop, Cursor, Cline, Continue, etc.) can connect to the server and call its tools without any per-provider integration code.

Browse every MCP server on the APIs.io network or compare with the broader Agent Skill surfaces of the same providers.

Work with this as data

Every MCP server here is available over the APIs.io API and to AI agents over MCP.

curl "https://apis.io/api/v1/mcp/corpole-mcp-server"

curl "https://apis.io/api/v1/mcp?limit=25"