# MCP Capabilities
URL: https://docs.autociso.io/developers/mcp/capabilities/
Description: What you can ask AutoCISO over MCP, grouped by the question you would ask, covering all 66 tools and the plan each needs.

The [Tool Catalog](https://docs.autociso.io/developers/mcp/tools/) is the exact reference — every argument and result shape. This page is the map: what an AI client connected to AutoCISO can actually answer, grouped by the question you'd ask.

All 66 tools are organisation-scoped and PII-masked by default. 61 are read-only; 5 write — and every write tool only ever produces a draft, a reversible edit or rehearsal text, never a publish. One read-only tool, `employee_resolve`, is the deliberate exception to masking and exists only behind the Owner-granted `pii:read` scope (scopes are explained in [MCP Auth and Scopes](https://docs.autociso.io/developers/mcp/authentication/)).

Which of the 66 your client sees depends on your organisation's [plan](https://docs.autociso.io/getting-started/plans-and-features/): each group below names the lowest plan that includes it, and the [Tool Catalog](https://docs.autociso.io/developers/mcp/tools/#plan-gating) shows it per tool in the **Requires plan** column. Tools outside your plan are not listed; upgrade and the same token sees them on its next `tools/list`.

## 1. Access intelligence

**"Who has access to what, and who has access they shouldn't?"** — the largest group, and the core of the product. The inventory itself is **All plans**; the reports are The Seed plan and above (three of them, plus the two below, need Growth).

`access_inventory_list` is the inventory: one row per employee × asset grant with role level, privileged flag, lifecycle status, first/last observed, last used, last verified and dormancy — paged, ID-only, filterable by employee, asset, status, identity type, role level and dormancy. It is the machine-readable answer to "give me every grant" that the console's [Access Inventory](https://docs.autociso.io/console/access/inventory/) page shows; pair it with `employee_resolve` when a person's name is needed.

Eleven further tools cover stale and orphaned accounts, [privilege concentration](https://docs.autociso.io/console/ciso-reports/access-concentration/), [privileged-access changes over the last 30 days](https://docs.autociso.io/console/ciso-reports/privileged-access-delta/), employees in [high-risk joiner/mover/leaver states](https://docs.autociso.io/console/ciso-reports/high-risk-lifecycle/), [anomalous access patterns](https://docs.autociso.io/console/ciso-reports/anomaly-discovery/), offboarding violations, [per-department risk scoring](https://docs.autociso.io/console/ciso-reports/department-risk/), [security-debt trend over time](https://docs.autociso.io/console/ciso-reports/security-debt-trend/), access-data normalisation health — the same reports the console shows under CISO Reports (for example [Stale & Orphaned Accounts](https://docs.autociso.io/console/ciso-reports/stale-accounts/)) — and, on The Growth plan and above, dormant "zombie" accounts correlated from activity signals and toxic access combinations (segregation-of-duties conflicts).

> *"Which accounts are stale, and which departments do they cluster in?"*

Tools: `access_inventory_list`, `access_stale_accounts`, `access_concentration`, `access_privileged_delta`, `access_high_risk_lifecycle`, `access_anomaly_discovery`, `access_offboarding_violations`, `access_department_risk`, `access_security_debt_trend`, `access_normalization_health`, `access_zombie_accounts`, `access_toxic_combinations`

## 2. Access reviews

**"Where does my review campaign stand?"** — The Growth plan and above.

Campaign status and completion progress for user access reviews (UAR), as on the console's [User Access Review Status](https://docs.autociso.io/console/ciso-reports/uar-status/) report. `access_reviews_list` returns `{ items, total }` of campaign summaries, never reviewer names.

> *"Is the Q3 access review on track, and what's outstanding?"*

Tools: `uar_status`, `access_reviews_list`

## 3. ISO 27001 posture

**"What are my gaps, and what's my Statement of Applicability status?"** — The Growth plan and above.

Gap analysis, SoA summary, the full control list with per-control gap status, the roadmap, the policy register, the readiness score and the evidence list. All accept an optional `projectId` and fall back to your first active [ISO project](https://docs.autociso.io/console/iso/projects/).

> *"Summarise my open ISO 27001 gaps by Annex A theme."*

Tools: `iso_gap_status`, `iso_soa_summary`, `iso_controls_list`, `iso_roadmap_list`, `iso_policies_list`, `iso_readiness_score`, `iso_evidence_list`

## 4. Risk register

**"What's on the register — and file this as a draft."** — The Growth plan and above.

Read the [Risk Register](https://docs.autociso.io/console/risk/register/), fetch one risk in full, and create a new risk as a draft.

> *"List open high-severity risks, then draft a new one for the finding we just discussed."*

Tools: `risk_register_list`, `risk_get`, `risk_create_draft`

**Note — The write tool is doubly gated**

`risk_create_draft` requires the `mcp:write` scope **and** writes enabled for the deployment. If either is missing, the tool is filtered out of `tools/list` entirely — the client never sees it. It always creates a *draft*; nothing is published to the register without human review.

## 5. Supplier and third-party risk

**"Which suppliers are unassessed?"** — The Growth plan and above.

The [supplier list](https://docs.autociso.io/console/directory/suppliers/) and assessment-status rollup — see [Supplier Assessments](https://docs.autociso.io/product/suppliers/assessments/).

> *"Which tier-1 suppliers still have an incomplete assessment?"*

Tools: `supplier_list`, `supplier_assessment_status`

## 6. Supplier questionnaire authoring

**"Clone this questionnaire and tighten the MFA question's weight."** — The Growth plan and above.

Read a questionnaire template's full content — including scoring fields no other MCP surface exposes — clone one into a new draft, and adjust a question's weight or an option's risk value. Every write here lands in a **draft**, never a live template. The human side of the workflow is in [Author and approve supplier questionnaires](https://docs.autociso.io/product/suppliers/questionnaires/); the REST equivalent is the [Supplier Questionnaires API](https://docs.autociso.io/api/reference/supplier-templates/list/).

> *"Clone the default supplier questionnaire and raise the weight on the encryption-at-rest question to 8."*

Tools: `supplier_questionnaire_list`, `supplier_questionnaire_get`, `supplier_questionnaire_validate`, `supplier_questionnaire_clone`, `supplier_questionnaire_update_question`, `supplier_questionnaire_update_option`

**Warning — No publish tool exists, and none ever will**

The three write tools require the dedicated `supplier_template:write` scope — `mcp:write` does not grant it — **and** must be enabled for the deployment, same as `risk_create_draft`. But there is no MCP tool that publishes a questionnaire, under any scope, and there never will be: publishing changes how every new assessment across the tenant is scored from that moment on, with no recall. An agent can reach `submitted` and no further; a human always publishes.

## 7. Supply chain security

**"Which SBOM carries the critical finding, and which vendor owns it?"** — The Growth plan and above.

The SBOM inventory with open-finding counts by severity, one SBOM's components, vulnerability findings by severity and status, and the vendor risk registry — the MCP counterpart of the [Supply Chain API](https://docs.autociso.io/api/reference/). Repository coordinates and vendor notes are never returned.

> *"List the SBOMs with open critical findings and the vendors behind them."*

Tools: `sscs_sbom_list`, `sscs_sbom_components`, `sscs_findings_list`, `sscs_findings_summary`, `sscs_vendor_list`, `sscs_vendor_risk_summary`

## 8. Audit and evidence

**"Show me the trail."** — the evidence log on The Seed plan and above; the audit trail and [evidence jobs](https://docs.autociso.io/console/operations/evidence-job/) on The Growth plan and above.

The [evidence log](https://docs.autociso.io/console/ciso-reports/evidence-log/), a searchable [audit trail](https://docs.autociso.io/console/settings/audit-trail/) filterable by exact actor ID, subject type, action and time window, and the automated [evidence-collection jobs](https://docs.autociso.io/console/operations/evidence-agent/) (blueprint, status, covered controls, classified error code — never logs or target URLs).

> *"What did this actor change last month, and did the branch-protection evidence job succeed?"*

Tools: `evidence_log`, `audit_trail_search`, `evidence_jobs_list`, `evidence_job_get`

Mind the result shapes here: `audit_trail_search` paginates and returns `{ items, total, truncated }` of projected entries (`seqNum`, `createdAt`, `actorId`, `action { code, group }`, `subjectType`, `subjectId`), while `evidence_log` returns at most 50 entries (same fields plus a server-side `chainStatus`, never the chain hashes) **with no continuation token** — a silent cap. The [Tool Catalog](https://docs.autociso.io/developers/mcp/tools/) flags every capped tool.

## 9. Compliance posture across frameworks

**"How covered are we, and which control satisfies which framework?"** — The Growth plan and above.

The unified posture score with per-framework scores, the coverage matrix, the control-objective list, crosswalk lookups from one framework's control reference to the shared objective, and the evidence shared across frameworks.

> *"Which SOC 2 controls are already covered by our ISO 27001 evidence?"*

Tools: `compliance_posture`, `compliance_coverage_matrix`, `compliance_objectives_list`, `compliance_crosswalk_lookup`, `compliance_shared_evidence`

## 10. Continuous monitoring and HIPAA

**"Which controls are drifting, and where do we stand on HIPAA?"** — Scale.

Monitoring status, per-control reliability, open compliance exceptions (optionally overdue only), and HIPAA readiness — crosswalk coverage for the HIPAA framework plus supplier BAA status counts.

> *"List the overdue control exceptions and summarise our HIPAA gaps."*

Tools: `monitoring_status`, `compliance_control_reliability`, `compliance_exceptions_list`, `compliance_hipaa_readiness`

## 11. Certification bodies and your certificate

**"Which certification bodies cover our industry — and is our certificate still valid?"** — the directory on The Growth plan and above; certificate status on Scale.

The shared [directory of ISO certification bodies](https://docs.autociso.io/console/iso/certification-bodies/) (accreditation, countries, industries, languages, average rating — never other organisations' review comments, contact URLs or pricing) and your own certificate's status, dates, issuing body and public verification URL when enabled.

> *"Shortlist UKAS-accredited bodies that audit fintechs in English."*

Tools: `iso_cb_directory_list`, `iso_cb_profile_get`, `iso_certificate_status`

## 12. Privacy operations (metadata only)

**"Which processing activities still need a DPIA?"** — Scale.

The [DPO cockpit](https://docs.autociso.io/console/privacy/cockpit/) counters, Record of Processing Activities entries, DPIA records and the [data dictionary](https://docs.autociso.io/product/privacy/data-dictionary/) — as metadata: names, purposes, lawful bases, statuses, review dates and retention periods. No contacts, notes, recipients, DSAR rows or DPIA answers.

> *"List active processing activities whose DPIA is still pending."*

Tools: `privacy_cockpit`, `privacy_activities_list`, `privacy_activity_get`, `privacy_dpia_list`, `privacy_dpia_get`, `privacy_data_dictionary_list`

## 13. Audit rehearsal (write)

**"Ask me what a Stage 2 auditor would ask about access control."** — Scale, `mcp:write`.

`iso_audit_simulate` puts one question to a simulated auditor working from your de-identified ISMS context and returns model-generated rehearsal text. It is a write tool (each call spends an AI request), rate-limited per token, and — like every write tool — dormant until MCP writes are enabled for your deployment. Treat the answer as practice, never as evidence or a finding.

> *"Rehearse: how would we evidence A.5.15 access control to a Stage 2 auditor?"*

Tools: `iso_audit_simulate` (`mcp:write`)

## 14. Executive posture

**"Give me the board-level summary."** — `maturity_scores` and `posture_summary` on every plan; `board_summary` on Scale.

Maturity scores per domain and a single-call posture summary — overall score, stale accounts, open risks, open ISO gaps, and the top concern. `posture_summary` returns useful data even for a fresh org, which makes it the best first call. On Scale, `board_summary` adds the board-and-executive roll-up.

> *"Give me a one-paragraph security posture summary for the board deck."*

Tools: `maturity_scores`, `posture_summary`, `board_summary`

## 15. Employee identity (opt-in)

**"Who is empl_1hgyun41rx48?" and "Which employee has this e-mail address?"**

Every other tool returns the opaque `employeeId` as a stable join key and masks the name. `employee_resolve` turns a batch of up to 50 IDs into `{ employeeId, name, email }` — but only for a token whose Owner deliberately granted `pii:read`, and every call is written to the audit trail before the result is returned. Use it once, for the IDs a person actually asked about, and keep the mapping on your side. See [Employee identity](https://docs.autociso.io/developers/employee-identity/) and [About `pii:read`](https://docs.autociso.io/developers/mcp/authentication/#pii-read).

> *"Resolve the five employee IDs from the stale-accounts report so I can email their managers."*

`employee_lookup` goes the other way: it maps up to 50 e-mail addresses to employee IDs and returns the IDs by input position only, never a name or an address. Both tools are `pii:read`.

Tools: `employee_resolve`, `employee_lookup` (`pii:read`)

## What MCP will not do

- **No cross-tenant access.** No tool takes an org identifier, and there is no header to set one. Your organisation is bound into the token and resolved server-side. This is enforced structurally: the server refuses to start if any tool declares an `orgId`-shaped input field.
- **No URL fetching.** No tool accepts a URL, endpoint, or callback argument — also enforced as a startup check, which closes off server-side request forgery.
- **No raw PII by default.** Results are masked before they leave the server: emails become `a***@domain.com`; `employeeName`, `department`, and `manager` are redacted. The opaque `employeeId` (`empl_…`) is returned as-is so you can join results across tools and map them to your own directory once. A tenant Owner can grant a token `pii:read`, which unlocks exactly two tools, `employee_resolve` and `employee_lookup`. `employee_resolve` returns name and email for explicit employee IDs only — at most 50 IDs per call, rate-limited per token, on a token that must expire within 90 days — and every resolution attempt that passes the scope check and the per-token rate limit — that is, every call that could have returned data — is written to your organisation's audit trail before the result is returned; rate-limited attempts return `RATE_LIMITED` with nothing disclosed and are not on the ledger (visible in the console and retrievable over MCP with `audit_trail_search` on plans that include Audit Trail — The Growth plan and above).
- **No directory export.** `employee_resolve` answers for the IDs you already hold; there is no search, no listing and no wildcard, and the per-call cap plus the per-token rate limit make enumeration visible in the trail long before it is useful.
- **No bulk export.** Tools answer questions; they are not a data-export channel. Several cap their results, list tools page at most 200 rows per call, and any result over 256 KiB is replaced by `RESULT_TOO_LARGE` (see [MCP Errors and Retries](https://docs.autociso.io/developers/mcp/errors/)).
- **No tools your plan does not include.** The tool list is derived from your organisation's plan; nothing outside it is registered for your token.