ki_hinweis
Formulierungsvorschlag für den KI-Hinweis nach AI Act Art. 50 Abs. 1 (de, fr, en, lb).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| firma | Yes | ||
| sprache | No | de |
Formulierungsvorschlag für den KI-Hinweis nach AI Act Art. 50 Abs. 1 (de, fr, en, lb).
| Name | Required | Description | Default |
|---|---|---|---|
| firma | Yes | ||
| sprache | No | de |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden, yet it never states that the tool is a pure text generator (no mutation), whether 'firma' is inserted verbatim into the notice, or what the returned text looks like. For a compliance-drafting tool with zero annotation coverage this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the deliverable and the legal reference front-loaded; nothing is padded. It is efficient but so terse that it omits the parameter meaning entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two params) and the description conveys the output artifact, so the core is covered without an output schema. It falls short on the required 'firma' parameter and on any hint about output structure or length, which matters for a legal notice template.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain both parameters. It does partially compensate for 'sprache' by enumerating de, fr, en and lb, which the schema itself never does, but 'firma' is completely unexplained despite being the only required parameter, leaving the agent to guess whether it is a company name, a brand, or a placeholder key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete deliverable (a suggested wording) and anchors it to a specific legal basis, AI Act Art. 50 Abs. 1, plus the four supported languages. An agent can tell this produces ready-to-use compliance text, though nothing distinguishes it from siblings like 'pflichten' or 'werbung_vorpruefen'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites, and no reference to the sibling tools that also touch AI Act obligations. The agent must infer that this is the drafting step rather than the obligation-lookup step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.