systemprompt.io reports

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses material behavior: the deterministic Annex III tree runs every call, user-supplied answers are binding while AI-derived answers are recorded as such, an AI workflow follows, and a paid call generates a PDF with a 72-hour link. It also surfaces the $1.50 payment requirement, which is critical behavioral context not present in annotations or schema.

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?

The description is long but tightly packed, with the core purpose front-loaded and each subsequent sentence adding a distinct fact about requirements, determinism, output composition, payment, or documentation. No sentence is filler; the length is justified by the tool's many contractual and behavioral details.

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?

For a five-parameter tool with payment, validation, and a rich output schema, the description covers the full calling contract: required versus optional/declinable inputs, the decision-tree constraint, the free validation step, the returned markdown/JSON/PDF artifacts, and the price. It even includes the documentation URL for edge cases, so an agent has everything needed to invoke it correctly.

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 100%, but the description adds decisive semantics: minimum character lengths, the exact use of the string 'declined', the binding nature of decision_tree_answers, and the mutual exclusivity with skip_decision_tree. It also explains how supplied versus declined inputs affect the input_coverage grade, which the schema alone does not convey.

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 opens with a specific verb and resource: 'Generate a structured EU AI Act compliance report' from named inputs, so an agent immediately knows what the tool produces. It also details the report's core contents (decision tree classification, article citations, obligations, evidence checklist), which fully distinguishes it from the only sibling, info.

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?

It states explicit invocation requirements: system_description is always required, model_card and data_flows accept content or 'declined', and exactly one of decision_tree_answers or skip_decision_tree must be sent. It also tells the agent that validation occurs before payment and points to full documentation and pricing, leaving no ambiguity about how to call the tool.

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

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

The annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: the tool is free, never returns a 402, and precedes paid operations. This goes beyond the annotation baseline without contradicting it.

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?

Every sentence earns its place: the tool's nature is front-loaded, followed by what it explains, cost safety, and the critical ordering instruction. The description is compact with no filler.

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?

For a simple, parameter-free info tool with an output schema and annotations, the description covers purpose, pricing behavior, payment options, and when to call it. Nothing essential is missing for an agent to use this tool correctly.

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?

There are zero parameters and the schema coverage is 100%, so no parameter documentation is needed. The description appropriately omits parameter details and instead focuses on usage context, matching the baseline for a no-parameter tool.

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 clearly identifies this as a free usage guide for the server, with a specific verb ('explains') and resource ('usage guide'). It explicitly distinguishes itself from the paid report tools by stating it costs nothing and should be called first.

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?

The description explicitly says 'Call this first before any paid tool,' giving a direct usage instruction. It also clarifies what the tool covers—input requirements, pricing, and payment—so an agent knows exactly when to invoke it versus a paid sibling tool.

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