MCP tools
Every tool the CorPole MCP server offers, the permission it needs and what it does. The server is at https://corpole.com/api/mcp.
Tools
| Tool | Access | What it does |
|---|---|---|
get_authority_context | Read | Every Authority record of the solution, grouped by type, with its acceptance criteria and their status, plus the agent instruction. Agents call it before writing or changing code. |
search_requirements | Read | Keyword search in title, code, statement and acceptance criteria. Defaults to Authority and Approved; Retired only on request. |
get_record | Read | Full detail of one record: state, statement, rationale, each acceptance criterion with its code (e.g. FR-001/AC2), status and evidence, satisfaction, owner, source, and unlinked technical requirements with similar wording. For a direction it also says whether it is in force and its chain (replaces, replaced by, or withdrawn with the reason). Also reads a decision, a question or another knowledge item of the solution by its code: type, state and text; for a decision who is said to have decided (marked as the relaying agent's claim) and how a person settled it — accepted or rejected, by whom, when and how, or "not theirs" said on its card; for a question its answer. |
get_work_context | Read | 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; for work items also the theme → epic → story/task → subtask chain, the work package and the implemented requirements (inherited from the nearest parent when an item has none). |
list_work_items | Read | Themes, epics, work packages, stories, tasks and subtasks with status, parent and the requirements they implement, e.g. the stories that are Ready. Stories are work that involves development; tasks are work without development. |
update_work_status | Write (propose permission) | 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. Approval, verification, check and Done are decided by people. |
get_standards | Read | Standards that apply to the solution (tenant-wide and solution; waived ones listed separately), with must/should enforcement. |
search_knowledge | Read | Search decisions, questions, glossary terms, standards and references. |
ask_question | Write (propose permission) | Records an open question with the working assumption, linked to what it concerns. |
propose_decision | Write (propose permission) | 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. A decision the person or someone else stated is recorded with record_decision instead, which keeps who decided and how. |
propose_relation | Write (propose permission) | Proposes a typed relation (refines, realizes, constrains, replaces, conflicts_with, relates_to). A person confirms it on the record page. |
create_project | Write (propose permission) | Creates a solution for the user in their workspace and switches an OAuth connection to it. An existing codebase starts onboarding; a new idea starts the kickoff interview. Under guided start CorPole asks the person in their AI client "Create the solution \"<name>\" in <workspace>?": their yes creates it, a no creates nothing. A client that cannot ask creates it as before, and the history records that the name was the agent's word (channel agent_stated). archetype (multi_tenant_saas, internal_tool, consumer_app or api_service) is only the agent's suggestion and is never stored: the answer tells the agent to put the solution type to the person as a question with the four types and their consequences, its suggestion recommended (FND-Q1); the person can also choose it in Solution settings. The answer then names the preparation: "Next: its preparation (get_setup_brief): the solution brief, the solution type and the mode come first." |
get_setup_brief | Read | 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 | Write (propose permission) | Stores one confirmed kickoff section: solution brief, Draft records with criteria and links, open questions. Nothing binds until a person approves it. Where the person's client can ask them, the section is confirmed there first; a section whose summary is too long to show whole in that question is not stored — send it in smaller parts or with shorter titles. |
propose_change | Write (propose permission) | Proposes a change to an existing record. Nothing is applied until a person accepts the difference on the record page; accepting follows the edit rules. |
get_package_brief | Read | The shared work package, masked: what to do, criteria and how they are checked, constraints, standards, agent policy. The first call of a package token. |
get_regression_candidates | Read | 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 | Write (propose permission) | Keeps a regression set of the solution or a UAT session of an initiative (filled with its criteria with from_initiative). People run it on one page. All or nothing. |
get_test_set | Read | A test set's items in order with roles and results so far, and its outcome once closed. |
report_test_set_result | Write (propose permission) | Records the result of a test item of a set, also as a run of the test. UAT scenarios without a test are recorded by people. |
get_test_history | Read | 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 | Write (person confirms; criteria.verify) | Quarantines a flaky test until it is fixed, or releases it. A quarantined test keeps running but is no evidence: its failures do not block, and its criteria cannot be Met by it. The person confirms in their own AI client, where the reason and the review date are shown; a reason too long to show whole is not asked and nothing changes. A service or package token never asks. |
propose_bulk_change | Write (propose permission) | Proposes the same change to many records with one reason, e.g. after a decision or a change in a regulation. All or nothing; people decide them together on one page or record by record, each under its record's rules. |
get_change_batch | Read | A bulk change proposal: its reason and source, and whether each record's change is open, accepted, rejected or superseded. |
propose_work_items | Write (propose permission) | Proposes epics, stories, tasks and subtasks into the Backlog. The agent can start one only after a person has moved it to Ready. The answer notes when their initiative answers no demand, so they cannot be committed under the enforced demand gate. |
get_handover_brief | Read | The solution's authority tier (Shadow, Shared, Full) and how to move agent rule files, requirement documents and ADRs into CorPole as proposals. Only a person changes the tier. |
declare_emergency | Write (emergency.declare) | 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 | Read | 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 request template and CI include). |
propose_record | Write (propose permission) | Adds a Draft marked as an AI proposal, with its acceptance criteria as separate items. Not binding until a person approves it. Limited to 30 per solution per hour. |
report_acceptance_result | Write (propose permission) | Records whether one acceptance criterion is met, with evidence. People see which agent reported it and can override it; the record's satisfaction updates. |
get_agent_policy | Read | 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. Called once per session. |
get_changes | Read | What changed since a moment: records, criteria, relations, work items, knowledge, tests and code links, with who, the field changes and the reason. Without since: since this agent last asked. |
check_code_area | Read | Before changing files: whether they are governed. During onboarding an ungoverned module is refused (enforced) or needs the user's agreement (advisory); a solution without any Authority record is treated the same until the kickoff has produced one. |
get_onboarding_brief | Read | How to bring an existing codebase under governance: the discovery protocol, the source trust order, the current modules and the maturity. |
submit_onboarding_findings | Write (propose permission) | Submits what was found in an existing codebase in one batch. Everything arrives as Drafts or proposals for people to review. |
leave_handover_note | Write (propose permission) | Leaves a note on an unfinished work item for whoever continues it: what is done, what is open, the next step. Shown at the top of get_work_context. |
link_code | Write (propose permission) | Attaches a pull request, commit, branch, file or CI run to a story, task or record. Connected repositories link pull requests that mention the code automatically. |
propose_test_case | Write (propose permission) | Registers a test that proves acceptance criteria. The automation reference must match how CI reports the test, so results update the criteria. |
report_test_result | Write (propose permission) | Reports one test run: passed, failed or blocked. Any failing active test makes its criteria Not met; all passing makes them Met. |
report_defect | Write (propose permission) | Records behaviour that breaks a requirement or criterion. Violated criteria become Not met until the defect is fixed and verified; people triage it first. |
raise_risk | Write (propose permission) | Records a risk in the register. It starts as Identified; people score it and decide the response. |
submit_retrospective | Write (propose permission) | Records lessons learned and improvement ideas. CorPole asks for this at most once a day. |
submit_handover_inventory | Propose | 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. Rows are matched by path. Answers with the readiness for the next authority tier. |
proceed_without_kickoff | Propose (records.authorize) | For a new solution without Authority records: records that the user chose to build without the kickoff interview, with the reason. The code gate stops asking and agents stop offering the interview until the first Authority record; a person can withdraw it on Solution settings. |
propose_rule | Propose (knowledge.edit) | Proposes behavioural rules for agents on this solution — from an agent rule file, a recurring lesson or the conversation — as Draft solution rules. Rules already in force or proposed in other words are skipped. They apply only after someone who manages the solution's integrations activates them on the Rules page. |
select_initiative | Write | 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 | Write | The same as switch_project, named for the delivery model: moves an OAuth connection to another solution. |
switch_project | Write | Moves an OAuth connection to another solution the user can open; every switch is written to both solutions' history. A token belongs to one solution: for a token connection the answer links the page where the user creates a token for the other solution. |
what_do_we_have | Read | 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 | Read | 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 | Read | 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 | Read | Quality and coverage scan: vague wording with no question, missing criteria, binding criteria with no test, conflicts, likely duplicates. |
review_test_fit | Read | 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 | Propose | 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 | Read | What the code must conform to: binding constraints, non-functional and technical requirements, active standards — narrowed to a path's module. |
report_conformance | Propose | Records a conformance review's table in the solution history; deviations reach the integrations owners. |
get_impact | Read | 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 | Propose | Keeps what should bind others in the solution: a Draft solution rule, constraint, standard or glossary term for approval. A personal working preference is not sent here — the agent keeps it in its client's own memory; a personal rule is kept in CorPole only when the person asks for it or the client has no memory of its own, and is then a Draft they turn on under Personal rules (in force at once only when they confirm it in a question their client shows them). What the agent says about the person's yes is not read. With direction true it records a direction exactly as record_decision does (the person's sentence word for word, waiting on its card). A permission (policy) is explained, not set. |
set_working_mode | Propose | 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 | Read | 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 | Propose | 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. Decides nothing. |
answer_question | Propose | Passes on the person's answer to an open question. Where the person's client can ask them, they confirm the exact answer there and it is recorded as theirs (confirmed in the client). Otherwise — also when the answer is too long to show whole in the client — it is kept as the agent's suggested answer, the question stays open, and the person applies it on the "Waiting for you" screen. The agent's word never makes an answer the person's. |
record_decision | Propose | 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. The sentence is one line; the white space around it is cut. The same statement the person accepted themselves within the last 24 hours — on the screen or in the client — (same title, text, decider and channel) is answered Accepted already: nothing is stored (after an accept in the client the person is not asked again either), and governs_codes or priorities the accepted decision lacks are not added (the answer says so and where the person adds them); later, or with another decider, it is a new decision. A statement a person called not theirs on its card is not stored again with the same title, sentence, decider and channel — a context, governs_codes or priorities added to it do not make it another statement; the same holds for Accepted already, and an open proposal of the same statement is returned as it is with a note that the added context was not stored, and relayed decisions take the hourly proposal limits (30 by one agent in a solution, 100 by all agents). A direction's sentence that looks like it holds a secret or personal data (an access token or key, a password, an address with a password, a card number, an 11-digit identity number) is refused, not masked: nothing is stored and the answer says what it looks like. In a solution under guided start an unconfirmed decision or direction opens its own card on Waiting for you (Confirm, Correct the wording, This is not mine), and the answer gives the card's address. A direction that resembles one in force is not asked in the client: replacing it or keeping both is the person's choice on the card (Confirm and replace, Confirm keep both), and the answer says so. Records a decision taken in the conversation, a meeting or by someone outside, with who decided and the channel. Accepted only when the person may decide and confirms the exact wording in a question their client shows them; otherwise — also when it is too long to show whole in the client — it is stored as a proposed decision on the agent's word, with who decided kept as the agent's claim, and a person accepts it on the screen. The same statement sent again is not stored twice, and an accepted call sent again changes nothing. An accepted call is "the same" only with exactly the same content; a corrected one the person confirms again is another decision. title and decided_by are one line each (line breaks, control characters and text-direction marks are refused). An accept stores the decision, its governs links and its priorities together or not at all; sent again after the decision was rejected or deleted on the screen, it writes nothing and says what the decision is now. Only the person's own connection (personal token or sign-in) is asked; a service or package token always leaves a proposal. Work priorities the decision names change only with the person's confirmation in the client; for a proposed decision they are never applied and the person sets them on the work items. The agent's word never makes a decision the person's. |
get_my_overview | Read | 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. Each solution read is logged in that solution. |
get_portfolio | Read | Old name of get_my_overview, kept as an alias. "Portfolio" now means the Lean Portfolio (get_portfolio_board, get_flow_metrics). |
get_status | Read | For a person's own connection it lists the directions in force (code and sentence, newest first), or says none is in force. Status brief. For me: what others changed since my last change, where I left off, what is blocked or failing on my work, what waits for me. For the solution: progress, decisions waiting, serious risks, drift, bottlenecks, maturity below target. For the team: people and their open work, agents waiting, alerts. |
get_maturity | Read | 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 | Write (the person confirms in their client) | 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. Making a record Authority is refused here: it binds every agent, so the person does it on the screen (the requirements board), where they read what the record says; the question in a client shows only its code and title. The confirmation counts for the records as they were when asked (type, priority, state, title, statement, rationale, acceptance criteria): one changed before the answer is asked again, and one changed while the approval is being written is reported as "changed while you were confirming; not approved". A list too long to show whole in one question is refused (approve fewer at once, or on the board); nothing is cut. Clients that cannot ask, and service or package tokens, send the user to the review board. |
get_audit_trail | Read (whole trail: integrations, owners, admins, auditors; others their own) | 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 | Read (tenant owners, admins, auditors) | 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 | Write (tenant owners, admins, auditors) | 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 | Read | 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 | Read (me: only your own) | 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 | Write (project.plan) | Names this moment and freezes records, criteria, work, tests, decisions and key numbers, to compare against later. |
compare_baseline | Read | 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 | Write (members; save false = read) | 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. demand re-assesses an existing one (members only; the assessments against other solutions stay), save false only previews. |
list_design_records | Read | The solution's design today by kind (BDR, FDR, NFDR, TDR, ADR), with version, drafts to confirm and pending changes. |
get_design_record | Read | One design record: description, acceptance, versions with the work, requirements and initiative behind each, and pending changes. |
propose_design_delta | Write | Records the design change an open work item carries (add, change, retire); applied as a new version when the work is Done. Warns when other open work changes the same record. |
get_flow_metrics | Read | 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 | Read | 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 | Read | What an initiative delivered: demands answered, design changes, delivered work, fixed defects, known limitations. |
get_evidence_pack | Read | 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 | Read | 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 | Read | 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 | Read | The workspace's demands with step, days in the step and linked initiatives. |
get_demand | Read | One demand: request, requester, channel, step, initiatives and the solutions they change, kept assessment. |
check_planning | Read | 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 | Read (integrations, owners, admins, auditors) | 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. Changes nothing. |
get_my_signals | Read | The connection's own open drift signals with why each matters, and the solution's accepted lessons. |
get_project_tour | Read | 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 | Read | MET-01…10 of the solution with targets and what each counts. |
track_requests | Read | 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 | Read | 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. |
Permissions
Read tools work on every connection. Write tools need the propose permission, and never make anything binding: they add Drafts, proposals or evidence for people to review. declare_emergency also needs the person to hold the emergency permission.