Clients and models

Ansvar works with any MCP client that supports Streamable HTTP and OAuth. For search and provision lookups, client and model choice barely matters. For workflows — threat models, gap analyses, DPIAs — it matters a lot. This page states what workflows demand of a client, which client capabilities meet that demand, which models we have tested, and the per-client limits worth designing around.

Workflow availability by plan: Premium runs threat-modeling workflows on a system you describe (metered monthly); Team and Company run the full catalog, including workflows over your own documents. See pricing.

What a workflow asks of your client

Measured against the live gateway on 2026-07-05 (STRIDE threat model, standard walk):

• 15 server-enforced steps. A typical walk takes 2–4 hours of session time — long enough that the gateway supports resume_workflow for OAuth tokens that expire mid-run. Save the workflow_id the gateway returns.
• MCP prompts, not just tools. Steps direct the client to invoke prompts such as /threat-modeler-scope-check. A client without prompt support can still proceed, but the operator pastes prompt text by hand at each step.
• Parallel sub-analyses. For the STRIDE enumeration phase alone, the gateway's recommend_subagents planner recommends 6 parallel subagent prompt-runs. Clients that cannot spawn subagents get an inline fallback: the same work, sequential, in one context window.
• Large tool results. One search call queried roughly 27 corpus servers and returned about 10 KB of cited rows. A full workflow walk accumulates tens to hundreds of kilobytes of fetched regulatory text in the client's context.

Client capabilities that matter

Search and lookups work on any client with Streamable HTTP + OAuth support. Setup walkthroughs exist for Claude (web + Desktop), Claude Code, VS Code / GitHub Copilot, Cursor, ChatGPT, Copilot Studio, Gemini, and Azure AI Foundry.

Workflows are strongest on clients with subagent and prompt support (Claude Desktop, Claude Code). On tools-only agent clients (GitHub Copilot agent mode and similar), workflows run through the inline fallback: expect longer sessions, keep the system description tight, and run enrichment passes one at a time. We have not yet load-tested a full workflow walk on Copilot agent mode; that guidance follows from the fallback path's design, not from a Copilot-specific run.

Per-client limits to design around

Observed in live triage during 2026-07 — client properties, not model properties, and independent of your plan:

• ChatGPT — no MCP prompt support (use describe_capabilities with section="tour" instead of the ansvar-tour prompt); a hard per-call timeout near 60 seconds with automatic duplicate retry (normal searches finish in a few seconds, so this bites only on very large scopes); instruction fields weight their opening lines heavily — put the scope rule first. Long chats have been observed dropping tools from context; a fresh chat restores them.
• Copilot Studio — the orchestrator follows the agent's Instructions field, not hints inside tool responses, so retry and broadening rules must live in the instructions. See Connect Copilot Studio for the connection-lifecycle warnings.
• Claude (web, Desktop, Code) — full MCP surface: tools, prompts, and (in Claude Code) subagents. This is the reference client for workflow walks.

What to look for in a model

Ansvar exposes up to a few dozen tools depending on plan, and real regulatory research is an agentic loop: scope, search, read, re-scope, cite. The model qualities that matter, in order:

1. Reliable tool calling — correct arguments across many tools, many turns. This is the floor; a model that fumbles tool schemas fails regardless of its reasoning quality.
2. Recovery behaviour — when a scoped query returns zero or noisy rows, does the model re-scope (switch query language, switch scope type, split the query) or accept the empty result and move on? Over a 15-step workflow this difference compounds.
3. Instruction following — the agent instructions only work if the model obeys them under pressure, including the refusal rule when results are empty.
4. Context capacity — workflows accumulate large fetched-text volumes; small context windows truncate mid-run.

Tested model configurations

Same task, same prompt, same account, run 2026-07-05: a five-pass regulatory enrichment scan (primary regime, horizontal regimes, sector routing, case law, authority guidance) for a German telehealth scenario, with a 15-call budget. Only Claude rows are filled so far because the test harness runs the protocol as Claude subagents — the GPT and Gemini runs are queued, and until they execute those rows stay honestly empty rather than guessed.

What separates the tiers is recovery. Real regulatory research hits scoped queries that return zero or noisy rows. Frontier models re-scope — switch query language, switch scope type — and recover; smaller models tend to accept the empty result and move on.

Practical guidance

• Use a frontier model with strong tool use for workflows. Smaller models handle simple searches fine.
• Query national corpora in their own language — and put that rule in the agent instructions, not in the user's hands.
• Expect long workflow sessions. Save the workflow_id and use resume_workflow after a token expiry.

Method

Model rows: one run per model (n=1), identical prompts, executed as agent-harness subagents against the production gateway on a company-tier account, 2026-07-05. This is a directional capability check, not a benchmark. Rows for Copilot, GPT, and Gemini stay unfilled until the same protocol runs on those surfaces. Workflow-demand numbers come from a live threat-model walk (15 steps, cancelled after measurement) and the gateway's recommend_subagents planner, same date. Per-client limits come from live customer triage in 2026-07; the OpenAI reasoning-effort finding comes from an internal qualification run on 2026-07-10.