Tool reference

The server exposes 11 tools. Eight of them are read dispatchers, one per domain, each covering many operations through a kind parameter. One returns reports, one performs every write, and one describes the rest. This shape is deliberate. An assistant handed sixty-five narrowly-named tools spends its context deciding between them and still picks wrong; eleven tools with explicit routes leave more room for your actual data.

You rarely need this page to use the server. Ask for what you want in plain language and the assistant picks the route. This is here for when you want to know exactly what it can reach, audit what an assistant did, or write a prompt that names a specific call.

Reads

Each read tool takes a kind and the identifiers that kind needs. All are read-only and scoped to your organization and your permissions.

`query_vendors`

Accepted parameters: kind, vendor_id, document_id, query, llm_query_terms, limit.

`kind`	Returns
`search`	Vendors matching a name or filter.
`count`	How many vendors you have.
`detail`	The consolidated profile: people, assessments, findings, contracts, engagements, obligations, radar alerts, documents. One call.
`people`	Contacts on a vendor.
`onboarding_status`	Where a vendor sits in onboarding. Takes an ID, not a name.
`documents`	Evidence files for a vendor, or org-wide.
`document_summary`	A summary of one document.
`document_download`	A download link for one document.
`risk_summary`	Risk tier and open finding counts.
`financial_health`	The Coverbase Financial Health Score: 0-100 score, risk band, confidence tier, pillar breakdown, financial vitals, peer percentile, adverse events, and the source behind each figure. Never compare scores across confidence tiers.
`company_registration`	Validated corporate identity from GLEIF, OpenCorporates, and SEC EDGAR: official name, status, jurisdiction, addresses, and LEI / DUNS / company number / CIK, each with a citation. Prefer this over a web search when a corporate fact is in question.
`bill_of_materials`	The currently applied SBOM, AIBOM, HBOM, or SaaSBOM and its components.
`bill_of_materials_history`	Every BOM received from this vendor, newest first.
`uses_nth_party`	Which of your vendors depend on a named nth-party.

`query_assessments`

Accepted parameters: kind, assessment_id, eval_id, vendor_id, status, query, control_set_id, issues_only, unresolved_only, limit, full_text, analysis_offset.

`kind`	Returns
`search`	Assessments by vendor, status, or assignee.
`detail`	Full assessment: control evaluations, findings with titles, people, documents.
`details_legacy`	The previous detail shape, for compatibility.
`evals`	Per-control evaluation results. Filterable to issues only or unresolved only.
`eval_detail`	One control evaluation in full, including the AI’s complete reasoning.
`plans`	Assessment plans.
`follow_ups`	Follow-ups attached to an assessment.

Reading a long AI analysis: eval_detail renders the AI’s reasoning whole up to a generous cap. If an analysis is longer than that, the response says so and names the follow-up call that returns the rest: pass full_text=true for every section at maximum length, or analysis_offset to page through the analysis from a given character. A capped response always announces itself, so a partial analysis is never presented as the complete reasoning.

`query_findings`

Accepted parameters: kind, finding_id, vendor_id, assessment_id, commitment_id, commitment_status, limit.

`kind`	Returns
`search`	Findings scoped to a vendor or assessment, or org-wide.
`detail`	One finding in full.
`list_detailed`	Findings with full titles, categories, assignees, due dates, status. Use this rather than `search` when you need titles.
`commitments`	Vendor commitments.
`commitment_detail`	One commitment in full.

`query_engagements_contracts`

Accepted parameters: kind, vendor_id, engagement_id, contract_id, vendor_document_id, status, limit.

`kind`	Returns
`engagements`	Engagements, optionally scoped to a vendor.
`engagement_detail`	One engagement in full.
`contracts`	Contracts by vendor or status.
`contract_detail`	One contract in full.
`services`	Services on a vendor.
`obligations`	Obligations extracted from vendor documents.

`query_controls`

Accepted parameters: kind, control_set_id, control_id, limit.

`kind`	Returns
`search`	Controls, optionally within one set.
`detail`	One control, including its AI evaluation guidance.
`control_sets`	Your control sets.

`query_questionnaires`

Accepted parameters: kind, questionnaire_id, questionnaire_type, vendor_id, intake_session_id, status, unanswered_only, pending_only, offset, limit.

`kind`	Returns
`list`	Your questionnaires.
`responses`	Responses to a questionnaire.
`intake_sessions`	Intake requests, filterable by status.
`intake_review`	One intake session as a reviewer sees it.
`intake_questions`	The questions on an intake, with AI drafts and reasoning. `pending_only` is the review queue: unanswered questions plus unconfirmed drafts.
`intake_prequalification`	The per-criterion screening verdict and its reasoning.
`intake_vendor_matches`	Ranked existing vendors and web alternatives for an intake.
`intake_steps`	Which steps this org’s intake portal turns on and off. Authoritative.

Vendor intake in chat

How these fit together into a complete intake request, and why intake_steps is read before anything else runs.

`query_radar`

Accepted parameters: kind, vendor_id, query, llm_query_terms, include_common_related_terms, limit.

`kind`	Returns
`detectors`	Radar detectors configured for the org.
`alerts`	Alert events, for one vendor or org-wide.
`reassessments`	Reassessments, including any started from a radar event.
`soc2_nth_party`	Which vendors depend on a named nth-party, searched across SOC 2 reports and custom relationships. Pass `llm_query_terms` with aliases: `AWS`, `Amazon Web Services`, `S3`, `EC2`.

`query_platform`

Accepted parameters: kind, object_type, object_id, target_type, target_id, query, include_inactive, limit.

`kind`	Returns
`notes`	Notes on any object.
`audit_trail`	The change history for any supported object.
`notifications`	Your notifications.
`tags`	Org tags.
`statuses`	The status labels defined for a target type.
`workflows`	Workflow automations.
`users`	Users in the org.

Reports

get_report(report_name, …) returns cross-cutting aggregations. Each report uses only some of the shared parameters.

`report_name`	What it returns	Parameters
`portfolio_risk`	Cross-vendor risk overview.	`top_n`
`assessment_metrics`	Completion and throughput over a rolling window.	`days`
`evidence_health`	Evidence coverage and gaps.	`vendor_id`
`review_queue`	Open findings and in-progress assessments.	n/a
`org_activity`	A broad program snapshot in one call.	`days`, `assessment_limit`, `finding_limit`, `radar_limit`, `activity_limit`, `notification_limit`
`control_flag_rates`	Controls ranked by how often they flag an issue. The data-driven way to find false-positive-prone controls to tune.	`days`, `top_n`, `min_volume`, `format`
`assessment_report`	An executive-ready writeup for one assessment.	`assessment_id`
`findings_by_vendor`	Vendors ranked by open finding count.	`top_n`

control_flag_rates accepts format='csv' for a spreadsheet-ready export.

Writes

Every write goes through one tool: mutate(entity, action, data). The per-action parameters go inside data.

Every write requires confirm: true inside data. A first call without it returns a confirmation prompt and changes nothing. The assistant is expected to show you the proposed change and wait. See Roles and permissions.

`entity`	Actions
`vendor`	`create`, `update`, `set_tags`
`service`	`create`, `update`, `set_tags`
`document`	`create`, `update`, `archive`
`tag`	`create`, `update`
`note`	`add`
`finding`	`create`, `update`
`obligation`	`create`, `update`
`control_set`	`create`, `update`
`control`	`create`, `update`
`eval`	`update`
`assessment`	`start`, `update`, `rerun`
`radar_detector`	`create`, `update`
`radar_event`	`create`
`radar_alert`	`dismiss`
`reassessment`	`create`, `update`
`custom_field`	`create`, `update`, `set_value`
`questionnaire`	`create`, `update`
`intake_session`	`create`, `update`, `prequalify`, `suggest_vendors`, `select_vendor`, `upload_document`, `answer`, `submit`, `approve`, `reject`, `request_follow_up`, `archive`
`questionnaire_response`	`set_status`
`review`	`create`, `update`
`contract`	`create`, `update`
`engagement`	`create`, `update`, `archive`

A few of these carry behaviour worth knowing:

vendor / create refuses by default

Creating a vendor directly requires skip_intake: true in addition to confirm: true. Requests to add, buy, or start using a vendor are supposed to go through intake_session / create instead, which links or creates the vendor itself. Creating one first leaves a duplicate carrying no due diligence.The separate flag exists because a generic “yes, create it” is not the same as accepting that due diligence is being skipped.

control / update tunes AI evaluation guidance

Editing a control’s expectation, evaluation instructions, or evidence requirement changes how the AI judges it. Material edits create a new version rather than overwriting. Pair it with get_report(report_name="control_flag_rates") to find the controls worth tuning, and assessment / rerun to re-evaluate against the new instructions.

eval / update triages one control evaluation

Clear a false positive with is_issue=false, resolve an issue, or attach review notes. This is the per-control correction, distinct from the whole-assessment sign-off in review / create.

engagement / archive is terminal

There is no unarchive.

Unknown fields are rejected, not ignored

Writes reject unexpected keys in data and return the accepted set. Silently dropping a misspelled vender_id would turn a typo into a successful mutation that quietly omits the field you meant to set.

Discovery

mcp_capabilities() takes no arguments and returns a JSON document enumerating every route above with its parameters: name, type, required or optional, and default value. It’s the recommended first call when an assistant isn’t sure which route applies, and it’s always current, because it’s generated from the running server rather than maintained by hand.

Example prompts

Realistic phrasing for each workflow, and which calls it resolves to.

Canned prompts

Nineteen scripted workflows you can invoke by name.

Roles and permissions

How read-only versus read/write is decided, and how it maps to your Coverbase role.

Security and privacy

What we log, what we don’t retain, and how to revoke access.

Getting started

Products

Control Set library

Trust & security

API Reference

Data Import & Export

Reporting & Templates

Integration Workflows

AI, Agents, MCP

Reads

`query_vendors`

`query_assessments`

`query_findings`

`query_engagements_contracts`

`query_controls`

`query_questionnaires`

Vendor intake in chat

`query_radar`

`query_platform`

Reports

Writes

Discovery

Example prompts

Canned prompts

Roles and permissions

Security and privacy

​Reads

​query_vendors

​query_assessments

​query_findings

​query_engagements_contracts

​query_controls

​query_questionnaires

Vendor intake in chat

​query_radar

​query_platform

​Reports

​Writes

​Discovery

​Related

Example prompts

Canned prompts

Roles and permissions

Security and privacy

Reads

`query_vendors`

`query_assessments`

`query_findings`

`query_engagements_contracts`

`query_controls`

`query_questionnaires`

`query_radar`

`query_platform`

Reports

Writes

Discovery

Related