Ansvar: EU Compliance & Legal Intelligence

Submit Response

submit_response

Provide an answer to the current step in a compliance workflow. Use this when someone provides information requested by the workflow, such as 'our system processes health data' or 'we use AES-256 encryption'. The workflow engine validates the response and advances to the next step. Pass user_acknowledged=true only after the user has supplied the fields listed in user_provided_fields. evidence_references accepts document UUIDs, doc:// segment URIs, or regulatory URLs. For an unattended gate, pass approved_by='auto' and leave user_acknowledged=false so the report does not misrepresent automation as human review. approved_by accepts only 'auto'; human review is asserted via user_acknowledged, never by naming an approver. Generate one UUID as submission_id and reuse it only when retrying the exact same payload after a timeout.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workflow_id": "<workflow_id>",
      "step_id": "<step_id>",
      "responses": "<responses>"
    },
    "name": "submit_response"
  }
}

Input Schema

Name	Required	Description
`step_id`	Yes	Id of the step being answered, as reported by get_current_step.
`responses`	Yes	The step's answers, keyed by the field names the step asked for. Values follow the expected input format get_current_step returned for that step.
`approved_by`	No	Accepts only 'auto', which marks the gate as passed unattended. Human review is asserted through user_acknowledged, never by naming an approver here.
`workflow_id`	Yes	Id of the workflow run, as returned by start_workflow. Recover a lost id with list_workflows.
`fetched_data`	No	Supporting material the agent gathered for this step — search results, provision text, document excerpts — passed through to the workflow engine alongside the answers.
`evidence_tier`	No	The evidence grade backing this answer, when the step asks for one. Omit unless the step's contract names it.
`submission_id`	No	Retry key for this exact payload. Generate one UUID per logical submission and reuse it only for byte-equivalent retries.
`compliance_level`	No	The compliance level asserted for this step, when the step asks for one. Omit unless the step's contract names it.
`user_acknowledged`	No	Set true only after the human has supplied the fields listed in the step's user_provided_fields. This is the assertion of human review; leave false for an unattended gate so the report does not present automation as human review.
`evidence_references`	No	References backing the answer: document UUIDs, doc:// segment URIs, or regulatory URLs.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / submission_id

Added value: +{
+  "description": "Retry key for this exact payload. Generate one UUID per logical submission and reuse it only for byte-equivalent retries.",
+  "title": "Submission Id",
+  "type": "string"
+}

Changed9 schema fields changedJul 31, 2026

addedInput schema / properties / approved_by / description

Added value: +"Accepts only 'auto', which marks the gate as passed unattended. Human review is asserted through user_acknowledged, never by naming an approver here."

addedInput schema / properties / compliance_level / description

Added value: +"The compliance level asserted for this step, when the step asks for one. Omit unless the step's contract names it."

addedInput schema / properties / evidence_references / description

Added value: +"References backing the answer: document UUIDs, doc:// segment URIs, or regulatory URLs."

addedInput schema / properties / evidence_tier / description

Added value: +"The evidence grade backing this answer, when the step asks for one. Omit unless the step's contract names it."

addedInput schema / properties / fetched_data / description

Added value: +"Supporting material the agent gathered for this step — search results, provision text, document excerpts — passed through to the workflow engine alongside the answers."

addedInput schema / properties / responses / description

Added value: +"The step's answers, keyed by the field names the step asked for. Values follow the expected input format get_current_step returned for that step."

addedInput schema / properties / step_id / description

Added value: +"Id of the step being answered, as reported by get_current_step."

addedInput schema / properties / user_acknowledged / description

Added value: +"Set true only after the human has supplied the fields listed in the step's user_provided_fields. This is the assertion of human review; leave false for an unattended gate so the report does not present automation as human review."

addedInput schema / properties / workflow_id / description

Added value: +"Id of the workflow run, as returned by start_workflow. Recover a lost id with list_workflows."

First observedJul 31, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare that this is a non-read-only, non-destructive, closed-world write, so the description carries real weight and delivers: the engine validates the answer and advances the step, approved_by accepts only 'auto', and submission_id is an idempotency key for byte-equivalent retries after a timeout. What is missing is failure behavior — what happens if validation rejects the response, or whether a partially valid payload is persisted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and the triggering situation, then moves to the three parameters that are easy to get wrong. It is dense but a few sentences duplicate schema field text almost exactly (evidence_references formats, approved_by only 'auto'), which is space that does not add information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter mutation with nested objects and a rich output schema, the description covers the pieces an agent could get wrong: which fields come from get_current_step, the human-review assertion, idempotent retry, and evidence citation formats. Return values need no explanation because an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and much of the description's parameter text (evidence_references formats, approved_by only 'auto', submission_id reuse, user_acknowledged semantics) restates the schema descriptions nearly verbatim. The one genuine addition is the cross-parameter instruction to pair approved_by='auto' with user_acknowledged=false for an unattended gate, which is not stated in any single schema field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Provide an answer to the current step in a compliance workflow') and implicitly separates itself from siblings like get_current_step (which reads the step) and start_workflow (which begins the run). The example answers ('our system processes health data') make the resource concrete rather than abstract.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the triggering condition ('Use this when someone provides information requested by the workflow'), and adds per-situation routing rules: unattended gate vs. human review, and when to reuse submission_id. It also tells the agent to leave user_acknowledged false in the automated case, which is a when-not-to-do-something instruction, not just a when-to.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Ansvar: EU Compliance & Legal Intelligence tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.