> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coverbase.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Tool reference
> Every tool the Coverbase MCP server exposes: the eight read dispatchers and their kinds, the report catalog, the write matrix, and the self-describing capabilities call.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
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. |
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](/mcp/permissions#write-protection).
| `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:
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.
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.
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`.
There is no unarchive.
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.
## Related
Realistic phrasing for each workflow, and which calls it resolves to.
Nineteen scripted workflows you can invoke by name.
How read-only versus read/write is decided, and how it maps to your Coverbase role.
What we log, what we don't retain, and how to revoke access.