Skip to main content
Glama

create_request_draft

Create a local YAML draft of a German freedom-of-information request for human review and approval before submission.

Instructions

Write a local YAML draft. RED tier, but performs NO network traffic at all.

The file starts in status ``draft`` with a placeholder confirmation token. A human
has to read the text, set ``status: approved`` and replace ``confirmation_token``
before anything can be submitted.

Args:
    path: where to write the YAML file.
    subject: request subject, 8-230 characters.
    body: the request text, at most 5000 characters.
    publicbody_id: recipient authority id.
    law_wunsch_id: the law you want to file under.
    law_api_default_id: the law the REST API would apply — see get_authority().
    law_wunsch_law_type: law_type of the desired law, e.g. "IFG" or "UIG".
    publicbody_name: authority name, for the L01 cross-check.
    publicbody_email: authority e-mail, for the L01 cross-check.
    ermittelt_ueber: how responsibility was established (a URL or a sentence).
    public: whether the request will be public. Public means CC0 and visible to all.
    full_text: True sends your text verbatim, False lets froide frame it.
    submit_via: "web_form" (human presses send) or "api" (immediate dispatch).
    dry_run: True (default) returns the draft without writing the file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes
pathYes
publicNo
dry_runNo
subjectYes
full_textNo
submit_viaNoweb_form
law_wunsch_idYes
publicbody_idYes
ermittelt_ueberNo
publicbody_nameNo
publicbody_emailNo
law_api_default_idNo
law_wunsch_law_typeNo

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?

With no annotations provided, the description carries full behavioral burden and does so thoroughly. It discloses that no network traffic occurs, that the file begins with status 'draft' and a placeholder confirmation token, that a human must approve/replace the token, and that dry_run returns the draft without writing the file.

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 front-loaded with the most critical facts (local draft, no network, human approval required), followed by a compact Args list. Every sentence adds value; the length is justified by the 14 parameters it documents.

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?

Despite having no annotations or output schema, the description gives the agent everything needed to call the tool correctly: the purpose, the safety profile, the approval workflow, parameter constraints, and dry_run behavior. Nothing essential 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%, but the Args list describes all 14 parameters with useful semantics: constraints (subject 8-230 chars, body max 5000), meanings ('public' means CC0), options (submit_via choices), and cross-tool references (law_api_default_id -> get_authority()). This fully compensates for the bare schema.

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 opens with a specific verb and resource: 'Write a local YAML draft', which clearly distinguishes this from submission, validation, or retrieval tools. It further clarifies scope with 'performs NO network traffic at all' and explains this is a preparatory step before a human approves and submits.

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?

It gives clear context for usage: this is a local, network-free drafting step that requires human approval before submission. It does not explicitly name alternatives or exclusion conditions, but the workflow context ('before anything can be submitted') makes the intended position in the process clear.

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