Scope Workflow
scope_workflowScope a compliance workflow down to ONE concrete workflow id before spending a run. This answers what the catalog cannot: which of the registry's ids fits THIS user's system, jurisdiction and framework. Call it with whatever you already know — every argument is optional — and it returns either the next scoping question with its allowed options (put that question to the user, then call again with their answer) or the single workflow_type to start, why that one, whether this caller may run it, and what a higher tier adds. Unmetered and visible at every tier: scoping never spends a run, and the recommendation is the same id whatever the caller pays, so a free caller sees what the product does before buying it. Deterministic — questions, options and the recommendation are projections of the workflow registry, never a guess. Every answer carries the registry snapshot it was computed from (fetched_at, age_seconds): the snapshot refreshes on an interval, so re-scope rather than replay an id across a registry change, and treat list_workflow_types as the authority when the two disagree. Typical opening: the user says 'Using Ansvar, we need a NIS2 gap analysis for our Dutch plant' — call scope_workflow(objective='gap_analysis', framework='nis2', jurisdictions=['NL']), then pass the id it returns to start_workflow. When the user asks which laws or regulations apply to their product, service or entity ('Using Ansvar, which laws apply to our EV charger in Sweden?'), the objective is 'regulatory_applicability_register'. Ambiguity comes back as the next question, never as a list of maybes, and every question's options are the complete set this tool accepts — for a framework it does not list, call list_workflow_types and start_workflow directly. A missing or stale registry snapshot fails explicitly; no static catalog is served as if it were live.
Tool call template
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "scope_workflow"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| framework | No | Control-set key the assessment is against, such as 'nis2', 'dora', 'cra' or 'eu_ai_act'. Pass 'none' when the user is not assessing against a framework. Take the value from the framework question's options rather than guessing a spelling — the key and the id suffix differ (gap_analysis_ai_act binds eu_ai_act). | |
| objective | No | What the user needs produced, as a workflow family value from a previous scope_workflow question's options — for example 'gap_analysis', 'threat_model', 'dpia', 'risk_assessment', or 'regulatory_applicability_register' for which laws apply to a product, service or entity. Leave empty on the first call and this tool asks for it. | |
| system_kind | No | Which kind of system is under assessment, as the exact value from a system_kind question's options — that question is how an IT product, an OT plant and a drone operation are told apart when framework and jurisdiction cannot separate them. | |
| jurisdictions | No | ISO-2 codes the assessment covers, such as ['NL'] or ['SE', 'EU']. Workflows with no jurisdictional variant stay eligible — they are the generic form. Pass ['unscoped'] to ask for that generic form on purpose. | |
| documents_available | No | Whether the user has documents (policies, SoA, supplier contracts) to ground the assessment in. Recorded and reported back; it does not change which workflow is recommended, because the registry publishes no per-workflow document requirement to decide it on. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |