Tool reference

Research — the core loop — All tiers (Free +) — exceptions marked per row

• search — Full-text search across in-scope sources, routed by jurisdiction, framework, sector, or source. Needs at least one scope. On Premium+ it automatically fans out into case law, preparatory works, and agency guidance, and the same call can narrow those evidence rows with court, date_from, and date_to (see Narrowing case-law evidence below). The query takes at most 500 characters: a longer one, such as a pasted case description, is refused before any source is searched, with error validation_error and code query_too_long (see Errors below). Search one legal issue per call, 2 to 5 terms, and merge the results.
• get_provision — One article, verbatim, by (jurisdiction, law, article) or canonical_ref — with source URL, publisher, license. Where a corpus keys its acts by identifier, pass the identifier as law and the article in the corpus's own shape: Book 7 of the Dutch Civil Code is law='BWBR0005290', article='7:677' (each book carries its own BWBR identifier). A U.S. federal regulation is addressed by its CFR citation: jurisdiction='US', law='45 CFR', article='164.410' reaches the one corpus that serves that CFR part (law='45 CFR Part 46', article='Part 46' for a whole part). A statute name resolves only where the corpus carries an alias for it; a miss names the search to run and the row whose lookup hint to replay.
• validate_citation — Check a citation resolves against the served corpus and get its current text for comparison — a deterministic, non-model check.
• validate_claim — Hand over the agent's reasoning as a claim graph (cited provisions with quotes, customer facts, assumptions, conclusions); the gateway refetches every provision under your access, binds the quotes, and reports the strength each conclusion can carry. Never a verdict. Guide: Validate a claim, under Guides.
• verify_citations — Send back the references a report relies on, each with its source_id and the quotation your text uses. For a provision, take source_id from the row's lookup hint; for a court decision or preparatory work, pass the routed corpus id the row came from (such as dutch-court-decisions), because those hints carry no corpus id, and never the citation's mcp_server display name. The gateway re-retrieves each one under your own access, checks the returned row's producer-declared identity against the reference, and only then compares your quotation with the body. One verdict per subject: quote_checked, reference_resolved, quote_mismatch, identity_mismatch, identity_absent, not_served, withheld, unavailable, plus no_quotation_submitted (an empty or too-short quotation) and reference_unparseable. A subject with no source_id, or on a corpus the identity check does not cover yet, returns identity_absent rather than passing; the response lists which corpora each lane covers. Lookups count against your normal lookup quota. All plans.
• list_coverage — What's live: by jurisdiction, by domain ("Using Ansvar: which jurisdictions for NIS2?"), by region, or by kind of legal text with content_kind: statute, court-decisions, preparatory-works or disciplinary-decisions ("Using Ansvar: which countries have court decisions?"). The telecom domain is telecommunications-media; domain='telecom' is accepted for it.
• discover_eu_legislation — Find EU legal acts by CELEX or ELI identifier, official title, reviewed alias, or a lexical (not semantic) match on title and EuroVoc labels, filtered by EuroVoc topic, sector, document type, or availability. Each candidate states its per-edition currency and any hold reason, names the eu-regulations framework key where the same act is keyed there, and carries the exact search and lookup hints to call next. All plans.
• get_changes — Change records from supported corpus feeds, including observed text changes in Dutch law. Read supported_scopes and each row's change_event: a text change is not automatically a legally identified amendment, and a baseline is not a change event. Availability depends on the routed source and your account; unsupported scopes return a refusal. For newly published acts, use search_regulatory_updates.
• search_regulatory_updates — What regulators newly published (EUR-Lex OJ-L, Commission DG CNECT, EDPB) — typed records with original-publisher deep links and CELEX ids. Premium and above.
• get_regulatory_update — One regulatory publication record by record_id — the lookup every search_regulatory_updates row names in its _citation.lookup. Premium and above.
• get_regulatory_deadlines — Dated obligation events that are coming — entry into force, application and phased application dates, transposition deadlines, compliance deadlines, repeals — soonest first, each row citing the provision that states the date. A request for an EU-27 member state also returns the EU-level rows that bind there; include_eu_level=false turns that off. The calendar is curated, not exhaustive: every response says so in its completeness field, and the absence of a row is not the absence of an obligation. Bills and unsigned instruments appear only behind include_pending, in a separate array, carrying their procedural stage and never a date. Premium and above.
• get_regulatory_intelligence_status — What the regulatory monitor actually watches and how current each source is: enrolled sources, publisher, channel, jurisdictions, last successful sync, freshness state. Free — check the watch surface before relying on it.
• diff — Version comparison of one provision needs a corpus that declares a gateway diff route. At this review (23 September 2026) no routed corpus declares one, so diff returns no results and an explicit unsupported-scope reason rather than a comparison; corpus-local version history does not make a gateway diff callable. Check live discovery before attempting a comparison.
• batch_search — Several scoped searches in one call — one quota draw per contained search.
• describe_capabilities / get_my_capabilities — Your tier's live tool list, sources, quotas, and limits. Use describe_capabilities(section='use_cases') for compact task entry points, describe_capabilities(section='sources') with query, domain, jurisdiction or content_kind to page through the sources, and get_my_capabilities for the live tool_surface fingerprints and refresh_hint.

Reading a search response

search starts with strict full-text matching across the sources in scope. A corpus can also match a controlled vocabulary term for your concept. These vocabulary-bridge rows serve by default as match_mode: "bridged"; they are assisted matches, not literal matches to your original terms. Strict rows keep their place before the assisted rows.

OR-style relaxation can match only some of your terms. The gateway withholds those rows; offer a re-run with allow_broadening=true and re-run only if they accept. Accepted rows carry match_mode: "broadened". A bare uppercase OR between alternative terms is an explicit either-or query. Do not rebuild this ladder in your own instructions: widening the query yourself changes what counts as a strict match.

The fields to read on a search response:

• results[].match_mode — absent on a strict match; "bridged" on a controlled-vocabulary match that can serve without consent; "broadened" on an OR-style relaxed match. On search, only the last requires allow_broadening=true. Preserve these labels when explaining what the source matched.
• meta.outcome — "NO_STRICT_MATCH" when at least one source was searched, every source answered, no access gate (licensing, entitlement, attribution) withheld a strict row, and no served row matched strictly. It means "these terms did not match", not "this law does not exist", and it is never a cue to answer from model memory.
• meta.recommended_action — "RETRY_ONE_CONCEPT_PER_CALL": the query carried three or more tokens after the gateway's sanitisation (stop words count) and asked for one row holding all of them; split it into one search per concept. The gateway never splits a query or adds terms to it; it does strip unsupported operators and punctuation before dispatch. "OFFER_BROADENING_TO_USER": the query already had one or two tokens (or an honoured OR), so splitting is not a recovery, and relaxed candidates exist; tell the user, offer a re-run with allow_broadening=true, and re-run only if they accept. It says nothing about whether your terms were the corpus's own vocabulary.
• meta.recommended_queries — optional short retry candidates drawn from your own terms, with the original scope. They accompany a clean multi-concept strict miss. Your agent chooses which to run; the gateway has not executed them. meta.recovery_guidance can also explain a refused or empty request. For a short query without relaxed candidates, REFORMULATE_OR_USE_EXACT_REFERENCE asks you to try the source's terminology or an exact provision reference.
• meta.broadening_available — set only on a strict miss (no served strict row, no access-gate withholding, at least one source searched): true when relaxed rows were withheld for this call, including on a partial fan-out where a source that did answer withheld them; false when none were on a clean fan-out; null when the answer is unknowable (a partial fan-out with nothing withheld) or when the field does not apply. When strict rows serve beside withheld relaxed rows, the offer is in meta.message and the count in query_broadened_sources[].withheld_results, which is always populated.
• meta.query_broadened_sources[] — one entry per source and relaxation rung (a source can appear twice under two modes): the source, the query as the corpus received it (requested_query, normalised after the gateway's sanitisation), the rung (mode: term_bridge, or_rank, strict+or_rank_merge, drop_trailing; empty on older corpus versions), and the rows withheld (withheld_results).
• meta.recommended_scopes — registered scope ids this call did not search, for example the delegated and implementing acts of a framework you scoped to. Absent when there is nothing to name; on a strict miss with nothing withheld, this is the recovery when it is present.
• meta.strict_row_provenance — on a jurisdiction-scoped search, how many served strict rows are national, EU-framework, or unclassified, so you can see when an NL-scoped answer is carried entirely by EU-level texts.
• meta.coverage_context — on a jurisdiction-scoped search with no strict row, the domains that jurisdiction's coverage spans, so an empty result is not read as "no such law".
• meta.off_topic_withheld_rows — rows removed by the relevance checks. Accepting broadening does not bypass those checks or guarantee that the candidate rows will serve. meta.message explains any withholding.
• meta.message — the prose form of the disclosures; the offer wording appears when relaxed rows were withheld. Read the typed fields; the prose is not a substitute for them.

allow_broadening defaults to false. Pass true only after the user accepted the offer or asked for relaxed matches. The flag does not gate vocabulary-bridge rows. Served OR-style relaxed rows arrive stamped match_mode: "broadened" and pass the same relevance floor as strict rows. search_guidance has no such flag today: its relaxed rows serve by default and carry the same stamp, so read match_mode there too; the strict-miss fields above (outcome, recommended_action, recommended_scopes, broadening_available) and the bare-OR disjunction are search only. The instruction wording that puts this into an agent's system prompt is on Instruct your agent.

Narrowing case-law evidence: court, date_from, date_to

Since 2026-09-03 search takes three optional filters. They apply to the evidence rows the Premium fan-out adds: the court filter to case-law rows, the date bounds to case-law rows and to preparatory-work and agency-guidance rows. Primary-law provisions carry no court, and the date bounds do not filter them: statute rows stay in the window whatever bounds you pass. Free and Solo searches carry no evidence rows, so all three are refused there with the upgrade note.

• court — an exact match on the corpus's own court value. Dutch courts are codes (HR, RVS, CRVB, CBB, GHAMS, RBAMS, RBDHA and the rest); other corpora may carry a court name. Read the value from the court field of a row returned without the filter before you filter. A value that matches no row is disclosed in meta.message, never served as a silent empty.
• date_from / date_to — inclusive bounds as full ISO dates (2026-01-01; a bare year is refused), on the decision date of case-law rows and the issue date of preparatory-work and guidance rows. date_to must not precede date_from.

Example: search(query='huurovereenkomst', jurisdictions=['NL'], court='RBAMS', date_from='2026-01-01'). The result window still places primary-law rows first, so when only decisions are wanted scope the call with sources=['dutch-court-decisions'] or raise limit. An argument the tool does not declare, a misspelt filter name for instance, is refused with JSON-RPC -32602 rather than ignored; see Errors below.

Vulnerability intelligence — All tiers (Free +)

• search_cve / get_cve_details — CVE search and detail from the live-synced CVE/NVD engine.
• get_epss_score / check_kev_status / get_exploits — Exploit-prediction score, CISA KEV membership, and known exploits for a CVE.
• search_by_product — CVEs affecting a product/vendor.
• search_ics_advisories / get_ics_advisory — CISA ICS/OT advisories — ICSA (general industrial), ICSMA (medical), ICSV (vendor). Search by keyword, vendor, advisory family, minimum CVSS, or publication date and get affected vendors, CVE counts, and severity; the lookup takes an advisory_id (ICSA-24-001-01) and returns the affected products with version ranges, the referenced CVEs with CVSS, the summary, and the CSAF source URL. Public-domain CISA CSAF data.
• get_data_freshness — Per-feed last-sync timestamps for the live data — how fresh the answer is.

The CVE intelligence engine serves these public facts from Free and includes feed-sync timestamps. Premium adds CAPEC, CWE, and D3FEND threat-pattern enrichment. Team adds effective-risk rescoring against customer asset context, review decisions, and OpenVEX export.

Legal evidence layer — Premium +

• search_guidance — Agency guidance from regulators, standalone (the guidance slice of the premium fan-out). The same 500-character query limit and query_too_long refusal as search.
• get_decision — One court decision plus its cross-references — the case-law analog of get_provision.
• get_preparatory_work — One preparatory-work record — bills, propositions, committee reports, legislative history — by jurisdiction and canonical reference; search surfaces the hits inside the premium fan-out.

Case law and preparatory works have no standalone search tool — they arrive inside search's automatic premium fan-out.

Document citation tools — Premium +

• get_document_segments / resolve_document_segment — Read uploaded documents at paragraph level and round-trip doc:// citations with content hashes.

These read-only citation tools do not include listing, uploading, deleting, or binding documents.

Document library & upload tools — Team +

• list_my_documents / register_document_init / register_document_finalize / register_document_text / delete_my_document — List, upload (presigned PUT, or register_document_text for pasted text), and delete documents in your document library (shared across your organization when your session carries your organization's identity; sign-ins without it see a personal library).

See the Cite your documents guide for the full loop.

Your standards — Premium +

• list_org_standards / get_org_standard_clause / search_org_standards — Query your organization's own uploaded standards and clause library the same way you query law.

Different surface from the SIS ISO standards add-on (licensed ISO text served by Ansvar) — see the ISO standards add-on guide under Guides.

Control library — Team +

• list_controls / get_control — Canonical controls on the NIST SP 800-53r5 spine plus ANSV-* extensions — filterable by control family, CSF 2.0 function, or applicability profile; one control returns its statement and the framework requirements it maps to.
• get_requirements — The framework requirements a canonical control maps to (ISO 27001/27002, NIS2, DORA, CRA, C5, 800-171, …), each with its relationship type and review status — review-approved mappings only by default.
• list_obligations — The standing obligations recorded under one framework edition — the reviewed obligation layer beneath the requirement nodes — without provision text. Filter by an exact requirement id or by review state (proposed, approved, declined); proposed rows are marked provisional. Every row carries its requirement's get_provision pointer, so the normative text resolves through the gateway at your corpus tier instead of being reproduced here. An unknown id or a framework with no obligation catalog is reported as such, never as an empty success.
• crosswalk — Framework A requirement → the canonical controls that satisfy it → framework B's requirements on those controls. Crosswalks route through the spine; only human-reviewed mapping claims count.
• resolve — A requirement id to its citation descriptor (source, edition, ref, and the gateway resolution parameters) — the clause text itself is then fetched through the gateway at your corpus tier.
• coverage — Mapping coverage against reviewed edges and composite assertions, optionally scoped to an applicability profile. Start with detail='summary'; use detail='requirements' with a framework and edition to page through requirement rows, filtered by status and paginated with limit/offset and page.next_offset. detail='full' returns the complete report. Omitted detail still means full in v0.3.5; pass it explicitly. Mapping coverage does not assert customer compliance.
• changes — Change-detection across catalog and mapping versions, plus drift of mapping edges against their resolved sources. Distinct from the corpus-side get_changes.

The library behind the /control-library page — one canonical spine, pointer mappings to the frameworks, coverage counted over reviewed claims only.

Workflows — Free + (metered teaser types) · interview-grounded catalog Premium + · complete catalog and document plane Team +

• scope_workflow — Answer a few scoping questions and get the right workflow_type for what you need produced — ambiguity comes back as the next question, never a list of maybes; pass the returned id to start_workflow.
• list_workflow_types / start_workflow / resume_workflow / list_workflows / cancel_workflow — Discover and manage structured workflow runs. Free includes 1 run/month and Solo 2 across seven types (threat model, gap analysis incl. NIS2/DORA/CRA/AI Act, DPIA) on a system you describe, with a watermarked render or JSON and no overage. Premium includes 5 across the full interview-grounded catalog with structured JSON reports. Team runs 20/seat/month, adds document grounding, and produces unwatermarked HTML, PDF, and DOCX exports.
• get_current_step / submit_response / get_progress — Drive a run: what's needed next, answer it, track it.
• generate_report / get_workflow_threats — The final deliverable and (threat workflows) the structured threat list.
• register_document / unregister_document / list_workflow_evidence / get_review_context — The document plane (Team+): bind uploaded documents to a run as evidence, list the evidence register, read a review gate's context.
• create_dfd / recommend_subagents — Threat-modeling specialists: validate and render a data-flow diagram; plan parallel sub-analyses for a phase.

Effective risk — Premium + inside workflow runs · Team + standalone

• effective_risk_inline / effective_risk_inline_batch — Context-supplied CVSS rescoring of a CVE, single or batch. Premium can call these only inside an admitted run of the vulnerability assessment, deferral dossier, or ICS advisory workflow; Team can call them standalone.
• simulate_control_investment — Rank hypothetical control investments by how much effective risk each would remove across your scored findings — an analysis, never a served score. Premium run-scoped (vulnerability assessment and deferral dossier runs); Team standalone.
• effective_risk — Rescoring against a persistent asset context. Team +.
• list_scoring_contexts / list_scoring_policies — Enumerate the asset contexts and rule sets the scorer can apply. Team +.
• record_review_decision / export_vex — Finalize an exploitability disposition and serialize it as an OpenVEX document. Team +.

Architecture workspace — Your own workspace (standalone or customer plane), not the hosted gateway

• arch_overview — Per-kind resource counts, trust zones with exposure, unclassified and uncontrolled asset counts, unmitigated threats, pending proposals and waiting import batches, when each kind last changed, bootstrap state, scoring readiness, and how well each kind's fields are cited and proven. The recommended first call.
• arch_search / arch_get / arch_list — Substring search across every resource kind; one resource by kind and id with its fields, resolved links, provenance, citations, and a proof level per field (optionally as it stood at an earlier revision); one kind listed with equality filters, where an unknown filter key is rejected rather than ignored.
• arch_list_components / arch_get_component — The immutable component version rows of one service, and one component by id.
• arch_list_assessments / arch_get_assessment — The assessments recorded against the model, filterable by kind and currentness (computed at read time), and one assessment with its dependencies and the causes that made it stale.
• arch_traverse — Breadth-first walk from a start node across the edge families, optionally restricted to a subset. Depth capped at 3; direction out, in, or both.
• arch_coverage — Compliance-obligation rollup by regime and assessment status, the obligations with no ADR or control evidence linked, unclassified and uncontrolled assets, plus findings such as zone crossings with no protocol or authentication and rows nobody has confirmed recently. Scope it to one regime when that's all you need ("Using Ansvar: which NIS2 obligations have no evidence linked?").
• arch_dfd / arch_export — Render a deterministic Mermaid data-flow diagram (the whole org, a zone, a list of services, or a C4 context or container view), or export the accepted graph as a lossless JSON bundle that imports into an empty workspace, or as Mermaid diagrams. Both read; neither writes.
• arch_questions — The open questions about your architecture, highest consequence first, each with the arch_propose or arch_confirm call its answer turns into. A question closes when its answer is approved.
• arch_verify_citations / arch_currency — Re-check a resource's field and edge citations (unchanged, moved, or unreachable) without changing the model; read one node's accepted revision, last confirmation, and what each enrolled source last saw of it.
• arch_sources / arch_observe — Enrol a local git repository as a source and observe it at its current commit. An observation returns one reviewable import batch with every field cited to commit and line; nothing applies on its own, and a node missing from a scan is never retired automatically.
• arch_propose / arch_propose_component / arch_propose_retire — Propose a create or update of one resource, a new immutable component version, or a soft retirement, each with the evidence behind it. Unknown fields, bad enum values, and links to ids that don't exist in your org are rejected. Each records a proposal; nothing changes until a reviewer approves, except inside a bootstrap window for the one machine principal it admits. Proposing a reference for an unkeyed row (kind re-key) always waits for a reviewer.
• arch_propose_re_review — Present a resource's full current state for a different reviewer to approve. This is how a self-approved row becomes reviewed. The reviewer must differ from both the proposer and the principal already recorded on the row. It changes no field and never auto-applies inside a bootstrap window.
• arch_list_proposals / arch_get_proposal — Your organization's proposals newest first, filtered by status, kind, or proposer; one proposal with its full diff, evidence, and the reviewer's comment.
• arch_review_proposal — Approve or reject a pending proposal. Org-admin only, agent seats refused, and the reviewer is never the proposer. Your comment goes on the record verbatim. A standalone workspace takes approvals in its browser review page; approving over MCP works only after the Owner enables it there.
• arch_import_batch — Stage a CSV or JSON file of nodes and edges as one reviewable batch, read it, and review it item by item. An org-admin approves; the server applies the dependency closure in one transaction, and no item ever retires a row. Inside a bootstrap window, a batch from the admitted principal with no conflicts applies on staging.
• arch_confirm — Record that a row is still true as of now. Org-admin only; a person asserts it, never an agent seat.
• arch_bootstrap — Read or control the seeding window. Any caller can read the status; start and stop are org-admin only. A window admits the proposals of one named machine principal, never a person and never the admin who opened it, for the kinds in scope, and expires within 24 hours.
• arch_grants — What each machine principal may do, on independent axes: read or read-and-propose, recording assessments, and observing one enrolled source. Review is never grantable. Org-admin only, reads included; agent seats refused.
• arch_workspace — The workspace's status: versions, profile, row counts, currency, and any open bootstrap window. On a standalone workspace file an org-admin can also back it up or clone it to a new machine, and the Owner can require citations on proposals; a plane workspace refuses backup and clone, since the operator backs up its database.

Your own security-architecture graph, queried by your agent the same way it queries law: services, data stores, flows, trust zones, controls, threats, vulnerabilities, ADRs, and compliance obligations. These tools are served by the architecture workspace you run yourself, on your machine under an evaluation or workspace licence or inside your customer plane; Ansvar never hosts your model, and the hosted gateway does not serve this family. A standalone workspace also advertises arch_record_assessment for its assessment producer, and standalone and plane workspaces add arch_list_stale_assessments and arch_scoped_read. Your workspace's own tools/list is the authoritative roster for the version you run.

Audit ledger — Company

• get_receipt / list_receipts / verify_receipt — Tamper-evident signed receipts: each query generates a cryptographic record of what was asked, what was returned, and when.
• export_audit_package / decrypt_receipt — Offline-verifiable audit bundle export; receipts decrypt client-side with your tenant's KMS key.