Skip to main content
Glama

submit_request

Send an approved freedom-of-information request to FragDenStaat.de after all validation gates pass. Use dry-run mode to verify every check without making the irreversible submission.

Instructions

Actually POST the request to fragdenstaat.de. RED tier — IRREVERSIBLE.

``POST /api/v1/request/`` sends the e-mail to the authority immediately. There is no
draft, no preview and no undo. Five gates therefore have to agree, in this order:

  1. the draft's status is ``approved`` (a human set it),
  2. no ERROR finding is open,
  3. ``law.wunsch_id == law.api_default_id`` — the API cannot set law_type, so a
     mismatch would file the request under the wrong act,
  4. ``confirmation_token`` matches the value a human wrote into the draft file,
  5. the local throttle ledger says another submission stays inside
     5/5min, 6/6h, 10/24h, 20/7d.

Args:
    path: path to the approved draft YAML file.
    confirmation_token: must equal the ``confirmation_token`` inside the draft file.
    dry_run: True (default) runs every gate and reports, but sends nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
dry_runNo
confirmation_tokenYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It clearly states that the action is IRREVERSIBLE, sends immediately, has no draft/preview/undo, and enumerates the exact gate conditions that control whether the request is actually submitted. This is unusually complete.

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

Conciseness5/5

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

The description is long but every sentence carries necessary safety-critical information. The irreversibility warning is front-loaded, the gates are listed in a clear numbered order, and the parameter explanations are tightly integrated rather than repeated from the schema.

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 high-risk, irreversible submission tool with no annotations and no output schema, the description covers the essential context: preconditions, gate order, parameter constraints, safety default behavior, and the fact that no undo is possible. Nothing needed to decide whether and how to invoke it is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must explain the parameters itself. It does: path is the approved draft YAML file, confirmation_token must match the value inside that draft, and dry_run defaults to true and prevents any sending. Every parameter is given meaningful semantics beyond its bare schema definition.

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?

The description names a specific action ('POST the request'), a target resource ('fragdenstaat.de'), and a clear scope ('sends the e-mail to the authority immediately'). It also distinguishes itself from sibling draft/build/validate tools by emphasizing this is the actual irreversible submission step, not a draft or preview.

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

Usage Guidelines4/5

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

The description gives strong contextual guidance: the five gates must agree before submission, and dry_run is presented as a safe way to test every gate without sending. It does not explicitly name sibling alternatives such as validate_draft or build_submit_url, so the when-not-to-use guidance is implied rather than fully explicit.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/notDIRK/fds-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server