MCP Tool Catalog

The AutoCISO MCP server exposes 66 tools: 61 read-only tools and 5 write tools — risk_create_draft, iso_audit_simulate, plus three supplier-questionnaire authoring tools (supplier_questionnaire_clone, supplier_questionnaire_update_question, supplier_questionnaire_update_option). One of the read-only tools, employee_resolve, is unmasked by design and appears only for a token carrying the Owner-granted pii:read scope — see About pii:read. Which of the 66 a given token sees depends on its scopes and on your organisation’s plan — see Plan gating. This page explains how to read the catalog and groups tools by area; the table at the bottom is generated from the same manifest the SDKs are built from, so it never drifts. For the same tools grouped by the question you would ask, see MCP Capabilities.

How to read the catalog

• Scope — mcp:read for every general read tool; mcp:write for risk_create_draft and iso_audit_simulate; supplier_template:read/supplier_template:write for the supplier-questionnaire tools (a separate scope family — mcp:write does not grant it); pii:read for employee_resolve.
• Requires plan — the lowest plan that includes the feature behind the tool. A token from an organisation on a lower plan does not see the tool in tools/list and cannot call it. All plans means the tool is available to every organisation.
• Arguments — taken from each tool’s published input schema. Most read tools take no arguments; every list tool takes limit and offset (see List conventions).
• PII masking applies to all results. Emails are masked to a***@domain.com; employeeName, department, and manager are redacted. A type that promises a real email is a lie — never rely on full identity fields in a result. The stable key is employeeId (an opaque empl_… identifier, never a national or HR number) — it is returned unmasked so you can correlate rows across tools and against your own directory.
• Result caps. Some older tools silently return a partial result set with no continuation token. The catalog flags each one. Every list tool added in the tier-coverage release pages with limit/offset and says so with truncated.

Typed results

12 of the 66 tools return a typed result: access_anomaly_discovery, access_normalization_health, uar_status, evidence_log, audit_trail_search, access_inventory_list, employee_resolve, employee_lookup and the four supplier-questionnaire tools. A successful call carries the result twice, as the usual text block and as structuredContent with the same masked JSON, so clients that read structured results need no parsing. The Result column in the table below shows which tools are typed and lists their top-level fields.

• Schema advertisement. The server adds outputSchema to tools/list for a typed tool only after the schema has been live for seven days. It never advertises one for employee_resolve, whose result depends on the token’s pii:read scope. The SDKs ship the types regardless.
• 54 tools are still untyped. They return JSON text as before and are marked Untyped with a tracking ticket. Typing them later is additive.
• Result size. A result over 256 KiB is replaced by RESULT_TOO_LARGE (see MCP Errors). A typed tool that returns nothing gives INTERNAL_ERROR.
• SDKs. See TypeScript SDK and Python SDK.

Plan gating

Scope and plan are two different questions. Scope is a property of the token (mcp:read, mcp:write, …); plan is a property of your organisation. A tool is registered for a token only when both are satisfied:

• Tools for features outside your organisation’s plan are absent from tools/list. They are unregistered for that token, not merely hidden.
• A call by name to an absent tool returns the SDK’s unknown-tool error (UNKNOWN_TOOL), exactly as a misspelled tool would.
• If a registration outlives a plan change — the org downgrades while a client still holds an older tools/list — the server answers NOT_PERMITTED with reason: "FEATURE_NOT_ENTITLED" and the feature ID that is no longer included. Refresh tools/list; nothing is retried.
• Scope ≠ plan. A mcp:write token on the Free plan still sees only the three All plans tools; a mcp:read token on Scale sees every read tool. Upgrading changes tools/list, not the token.

{ "error": "NOT_PERMITTED", "reason": "FEATURE_NOT_ENTITLED", "feature": "privacy_operations" }

The generated table’s Requires plan column is derived from the same pricing configuration the console uses, so it cannot drift from what user menu → Billing & Subscription shows.

List conventions

Every list tool takes the same two arguments and returns the same envelope:

• limit — default 50, maximum 200. Larger values are clamped, not rejected.
• offset — default 0.
• The result is an object: an items array under a tool-specific key (items, accounts, jobs, sboms, …), total (the full count) and truncated: true when the page did not reach the end.
• Any result — list or not — whose serialised size exceeds 256 KiB is replaced by the error RESULT_TOO_LARGE with the limit in bytes. Narrow the filters or lower limit; the SDKs do not retry it. See MCP Errors and Retries.

Name keys. MCP masks the generic name key on every result, because in most tools it is a person’s name. Tools whose “name” is a product, package, vendor, activity or certification body return it under a specific key instead: sbomName, componentName, vendorName (supply chain), activityName, entryName (privacy metadata) and bodyName (certification bodies). Read those keys; do not expect name.

Access (12 tools)

access_inventory_list, access_stale_accounts, access_concentration, access_privileged_delta, access_high_risk_lifecycle, access_anomaly_discovery, access_offboarding_violations, access_normalization_health, access_department_risk, access_security_debt_trend, access_zombie_accounts, access_toxic_combinations.

These power the access-intelligence surface — the same data as the console’s CISO Reports, such as Stale & Orphaned Accounts and Offboarding Violations. Results carry masked identity fields but keep employeeId as the join key. access_security_debt_trend accepts an optional months argument (default 6). The first six plus evidence_log are The Seed plan and above; access_privileged_delta, access_department_risk and access_security_debt_trend are The Growth plan and above.

access_inventory_list (All plans) is the inventory itself rather than a finding: one row per employee × asset grant, paged (limit default 50, max 200; offset), returning { grants[]{ accessId, employeeId, assetId, assetName, assetCriticality, identityType, roleLevel, roleOrigin, roleConfidence, isPrivileged, status, firstObservedAt, lastDetectedAt, lastUsedAt, lastVerifiedAt, isDormant, dormantDays, riskScore, riskFactors[], updatedAt, accountState, revokedAt, revocationSource }, total, truncated?, next? }. Filters: employeeId, assetId, status (ACTIVE default, REVOKED, ALL), identityType (HUMAN, SERVICE_ACCOUNT), roleLevel (ADMIN, MANAGER, VIEWER), isDormant. isPrivileged is roleLevel == ADMIN. Rows carry employeeId and assetId only — never a person’s name or e-mail (resolve IDs with employee_resolve); grants held by terminated employees are included. firstObservedAt is the first time AutoCISO observed the grant, not the date it was granted in the source system. Asset names are organisational data as entered in AutoCISO. Unknown arguments and wrong-typed values are rejected with INVALID_ARGUMENTS. To build a complete per-employee entitlement list, page with status: "ALL" until truncated is absent, then resolve names in batches of 50 with employee_resolve. status is no longer always ACTIVE: a grant revoked in the console, by a reviewer correcting a detected match, or by a snapshot review is kept as a REVOKED row with revokedAt (the effective revocation time) and revocationSource (MANUAL, SNAPSHOT_REVIEW or MATCH_CORRECTED), so status: "ALL" now returns revoked grants as well as active ones. A later detection that is newer than revokedAt makes the grant ACTIVE again and clears both fields; an older or replayed audit never does.

updatedAt is the time of the last write to the grant (null until the row is backfilled). accountState is the account state the source system reported (ACTIVE, SUSPENDED, BLOCKED, INVITED; UNKNOWN by default, never guessed). It is read from the status column of an audit export (a CSV status, state or active column, or the status shown in a screenshot or PDF); UNKNOWN means the source did not report a state, not that the account is healthy. A later audit that does not report a state keeps the stored one, and a state set by a reviewer is kept the same way. revokedAt is null for an active grant and revocationSource is empty (MANUAL, SNAPSHOT_REVIEW or MATCH_CORRECTED once a revocation is recorded). The tool has no isUsable field: decide from status and accountState.

Incremental sync. Pass updatedAfter (RFC3339 with a time zone, for example 2026-10-01T12:00:00Z) to list grants written at or after that instant, in the fixed order (updatedAt, accessId). While truncated is true, pass next.updatedAfter and next.afterAccessId back to continue strictly after the last row; total then counts the rows after the cursor. offset cannot be combined with these arguments, and an invalid timestamp or afterAccessId returns INVALID_ARGUMENTS. Rows whose updatedAt is null are not returned. Re-poll with an overlap window (start a few minutes before the newest updatedAt you saw) to absorb clock skew, and expect repeats: every re-detection of a grant stamps updatedAt. isDormant and dormantDays are computed when you read and change without moving updatedAt, so derive them from the dates. Use status: "ALL" to include revoked grants in the sync.

Two tools are new: access_zombie_accounts (The Growth plan and above, Zombie Hunter) correlates activity signals and returns { accounts[]{ employeeId, assetId, assetName, dormantDays, lastActivityAt, signals[] }, total } — minDormantDays defaults to 90; access_toxic_combinations (The Growth plan and above) returns { combinations[]{ employeeId, criticalAssetIds[], conflictType, riskScore }, total } — minCriticalAssets defaults to 2.

const stale = await client.access.staleAccounts();
const debt  = await client.access.securityDebtTrend({ months: 12 });

stale = client.access.stale_accounts()
debt  = client.access.security_debt_trend(months=12)

Reviews (2 tools)

uar_status (The Growth plan and above), access_reviews_list (The Growth plan and above, ISO 27001) — user access review status and campaign completion, as on the User Access Review Status report.

access_reviews_list now returns a wrapped object, { items, total }, where each item is a campaign summary — campaignId, projectId, campaignName, status, period, dueAt, sentAt, completedAt, reviewerCount, reviewersByStatus, assetCount. Reviewer names are never included. Code that treated the result as a bare array must read .items.

ISO 27001 (8 tools)

iso_gap_status, iso_soa_summary, iso_controls_list, iso_roadmap_list, iso_policies_list, iso_readiness_score, iso_evidence_list (all The Growth plan and above) and iso_audit_simulate (Scale, write). Each read tool accepts an optional projectId; if omitted, the first active ISO project is used.

The four new read tools mirror the assistant’s ISO tools: the roadmap (task, control, priority, status, due date — no free-text descriptions), the policy register with status counts, the readiness score and the evidence list.

const gaps = await client.iso.gapStatus();
const soa  = await client.iso.soaSummary({ projectId: 'iso_…' });

gaps = client.iso.gap_status()
soa  = client.iso.soa_summary(project_id="iso_…")

Risk (3 tools)

risk_register_list, risk_get, and the write tool risk_create_draft — all The Growth plan and above.

const risks = await client.risk.registerList();   // finalized only
const one   = await client.risk.get({ id: 'risk_…' });

risks = client.risk.register_list()   # finalized only
one   = client.risk.get(id="risk_…")

// Requires mcp:write + MCP write enabled for your org.
const draft = await client.risk.createDraft({ title: 'Vendor X data residency' });
// On a read-only org this throws AutocisoPermissionError (NOT_PERMITTED).

# Requires mcp:write + MCP write enabled for your org.
draft = client.risk.create_draft(title="Vendor X data residency")
# On a read-only org this raises AutocisoPermissionError (NOT_PERMITTED).

Suppliers (2 tools)

supplier_list, supplier_assessment_status — third-party inventory and assessment completion. The Growth plan and above (Supply Chain Security).

Supplier Questionnaire Authoring (6 tools)

supplier_questionnaire_list, supplier_questionnaire_get, supplier_questionnaire_validate, supplier_questionnaire_clone, supplier_questionnaire_update_question, supplier_questionnaire_update_option. The Growth plan and above.

These author draft supplier-assessment questionnaires — cloning a template and adjusting a question’s weight or an option’s risk value, all inside a draft. The three read tools require supplier_template:read; the three write tools require supplier_template:write. Neither scope is implied by mcp:read/mcp:write — they are a dedicated family, because the read tools return the full scoring model (weight, riskValue, findingSeverity, controlIds) that no other MCP-reachable surface exposes.

const draft = await client.supplier.questionnaireClone({ sourceTemplateId: 'satpl_builtin' });
await client.supplier.questionnaireUpdateQuestion({
id: draft.templateId, questionId: 'q1', weight: 8,
});

draft = client.supplier.questionnaire_clone(source_template_id="satpl_builtin")
client.supplier.questionnaire_update_question(id=draft.template_id, question_id="q1", weight=8)

Supply Chain Security (6 tools)

sscs_sbom_list, sscs_sbom_components, sscs_findings_list, sscs_findings_summary, sscs_vendor_list, sscs_vendor_risk_summary — The Growth plan and above. The MCP counterpart of the Supply Chain API: SBOM inventory with open-finding counts by severity, one SBOM’s components (purl, componentName, version, licence — at most 200 per call), vulnerability findings filterable by severity and status, and the vendor risk registry. Repository coordinates (URL, branch, commit) and vendor notes are never returned. The product, package and vendor names arrive as sbomName, componentName and vendorName.

Evidence & Audit (4 tools)

evidence_log (capped at 50 entries, The Seed plan and above), audit_trail_search (The Growth plan and above, Audit Trail), evidence_jobs_list and evidence_job_get (The Growth plan and above, Automated Evidence).

audit_trail_search reads the same ledger as the console’s Audit Trail and returns a wrapped object — { items, total, truncated } — not a bare array. Each entry is projected to { seqNum, createdAt, actorId, action { code, group }, subjectType, subjectId }: no names, no change payloads, no chain hashes. evidence_log returns the same fields plus chainStatus (verified or not), computed on the server. actorId is a usr_… ID, an apitoken:… reference or a system literal. Filter by exact actorId, subjectType or action and by a from/to window; page with limit/offset.

The two evidence-job tools list automated evidence-collection runs — blueprint, status, timing, covered control IDs, a classified errorCode and the artifact count. Job logs, target URLs, raw errors and artifact contents are never returned.

const page = await client.audit.trailSearch({ limit: 25, offset: 0, action: 'api_token.created' });
console.log(page.items.length, 'of', page.total, page.truncated ? '(more)' : '');

page = client.audit.trail_search(limit=25, offset=0, action="api_token.created")
print(len(page.items), "of", page.total)

{
  "items": [
    {
      "seqNum": 1842,
      "createdAt": "2026-09-15T08:00:00Z",
      "actorId": "usr_…",
      "action": { "code": "api_token.created", "group": "api_token" },
      "subjectType": "api_token",
      "subjectId": "apitok_…"
    }
  ],
  "total": 184,
  "truncated": true
}

Compliance & Monitoring (9 tools)

• Compliance Cockpit (The Growth plan and above): compliance_posture — the unified posture score with per-framework scores; compliance_coverage_matrix — coverage rows { objectiveId, framework, status, evidenceCount }.
• Multi-framework crosswalk (The Growth plan and above): compliance_objectives_list, compliance_crosswalk_lookup (framework + controlRef), compliance_shared_evidence (objectiveId).
• Continuous control monitoring (Scale): monitoring_status, compliance_control_reliability, compliance_exceptions_list (overdueOnly).
• HIPAA (Scale): compliance_hipaa_readiness — crosswalk coverage for the HIPAA framework (objectives, covered, gaps[]) plus supplier BAA status counts.

Board (1 tool)

board_summary (Scale) — the board-and-executive roll-up the assistant uses for the same question. For a first call on any plan use posture_summary instead.

Certification (3 tools)

iso_cb_directory_list and iso_cb_profile_get (The Growth plan and above, Certification body directory) return the shared directory of ISO certification bodies — certBodyId, bodyName, shortName, accreditedBy, countries[], industries[], languages[], avgRating, reviewCount, active. Other organisations’ review comments, contact URLs and pricing are never included. iso_certificate_status (Scale, Certificate management) returns { status, issuedAt, expiresAt, certBodyName, publicVerificationEnabled, verifyUrl? } — verifyUrl only when the public verification page is enabled. Like the audit simulator, it is gated more strictly over MCP than the console page it mirrors.

Privacy (6 tools)

privacy_cockpit, privacy_activities_list, privacy_activity_get, privacy_dpia_list, privacy_dpia_get, privacy_data_dictionary_list — all Scale (Privacy operations), the metadata behind the console’s DPO Cockpit. These return metadata only: cockpit counters; RoPA activities as activityName, purpose, lawful basis, role, category and supplier references, status, DPIA requirement and review dates; DPIA records as status, decision and finalisation date; data-dictionary entries as entryName, category, special-category flag and retention. No contacts, notes, recipients, DSAR rows or DPIA answers are ever returned.

Maturity & Posture (2 tools)

maturity_scores (capped result set), posture_summary (a single roll-up — the recommended first call). Both are All plans.

Employee identity (2 tools)

employee_resolve and employee_lookup — All plans, but only for a token carrying the Owner-granted pii:read scope. See About pii:read and Employee identity.

employee_lookup maps e-mail addresses to employee IDs (the reverse of employee_resolve):

• Input: emails, 1 to 50 addresses per call. Each address is trimmed, lower-cased and de-duplicated before the cap is applied, so repeating an address does not use up the 50. An address must be plain ASCII with exactly one @ and at most 254 characters. One malformed address rejects the whole call with INVALID_ARGUMENTS; the error never repeats what you sent. To look up more than 50 addresses, call again with the next batch.
• Output: { matches: [{ index, employeeId }], unmatchedIndexes: [], ambiguousIndexes: [], normalizedCount }. index is the position in the de-duplicated, normalised list (normalizedCount long), not in your original array. The result contains no name and no e-mail address. Every array is always present, empty when there is nothing to report.
• Ambiguity: an address held by more than one employee, including as the primary address of one and an alias of another, is listed in ambiguousIndexes and is never guessed. Any employee status matches, including terminated and onboarding employees. Matching is exact; there is no prefix, wildcard or pattern search.
• Rate limit, all or nothing: every de-duplicated address you submit costs one unit of the token’s hourly personal-data allowance, whether or not it matches. If fewer units remain than addresses submitted, the call returns RATE_LIMITED and spends nothing.
• Audit: every call is written to your audit trail before the result is returned, with the counts, the matched employee IDs and unmatched addresses in masked form (s***@domain.com). Raw addresses are never stored.

Generated tool reference

The table below is generated from the committed MCP manifest at build time — the same artifact the SDKs are generated from. It always reflects the live tool surface.

66 tools (61 read-only, 5 write). Generated from the committed MCP manifest (the same artifact the SDK is built from).

Results are PII-masked by default: emails become a***@domain.com and personal names are redacted. The Masked column flags tools whose results commonly carry identity fields; the one exception, employee_resolve, is available only to a token carrying the Owner-granted pii:read scope and returns real names and emails for explicitly requested employee IDs. The Result column shows whether the tool has a typed result and lists its top-level fields; Untyped tools return JSON without a published schema. The Result notes column flags pagination and silent result caps.

Requires plan is the lowest plan whose feature includes the tool. A token from an organisation on a lower plan does not see the tool in tools/list and cannot call it; All plans means every organisation. Scope and plan are independent gates — see Scope is not entitlement.