MCP Capabilities

The Tool Catalog 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).

Which of the 66 your client sees depends on your organisation’s plan: each group below names the lowest plan that includes it, and the Tool Catalog 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 page shows; pair it with employee_resolve when a person’s name is needed.

Eleven further tools cover stale and orphaned accounts, privilege concentration, privileged-access changes over the last 30 days, employees in high-risk joiner/mover/leaver states, anomalous access patterns, offboarding violations, per-department risk scoring, security-debt trend over time, access-data normalisation health — the same reports the console shows under CISO Reports (for example Stale & Orphaned 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 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.

“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, 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

5. Supplier and third-party risk

“Which suppliers are unassessed?” — The Growth plan and above.

The supplier list and assessment-status rollup — see Supplier 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; the REST equivalent is the Supplier Questionnaires API.

“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

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. 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 on The Growth plan and above.

The evidence log, a searchable audit trail filterable by exact actor ID, subject type, action and time window, and the automated evidence-collection jobs (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 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 (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 counters, Record of Processing Activities entries, DPIA records and the 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 and About 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).
• 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.