FluxProof

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

Annotations already cover readOnlyHint=false and idempotentHint=false. The description adds useful behavioral context beyond annotations: consumes check quota, stores a receipt, and may deliver a configured webhook. It also reiterates the non-idempotent nature. No contradiction with annotations.

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?

Three sentences, zero waste. The main purpose is front-loaded, side effects follow, and the clarifying 'not an idempotent read' is a useful closing distinction. Every sentence earns its place.

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 2-parameter tool with no output schema, the description covers the action, side effects, and a hint about the receipt content. It doesn't detail the receipt format or error cases, but for a trigger-like tool this is adequate. A little more detail on the receipt would push it to 5.

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 description coverage is 100% – both api_key and monitor_id have adequate descriptions. The tool description adds no parameter-specific meaning beyond the schema, so baseline 3 is appropriate. It mentions the output receipt but not parameter details.

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 states a specific verb ('Run a monitor now') and resource ('monitor'), and clarifies the output ('source- and hash-bound change receipt'). It explicitly disambiguates from a read by saying 'Not an idempotent read', which distinguishes it from sibling list_changes. This is clear and specific.

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 implies when to use it (to trigger an immediate check) and warns about quota consumption, which helps decide. However, it does not explicitly name alternatives or state when not to use it (e.g., 'if you only need past changes, use list_changes'). The exclusion is implicit via 'not an idempotent read', but not fully explicit.

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 description discloses important behavioral traits beyond the annotations: it creates persistent state, performs a baseline check, consumes quota, and is not idempotent. This aligns with idempotentHint=false and readOnlyHint=false, and adds context about quota consumption and the retry caution. It does not describe return format or error handling, but the annotations already set the safety profile.

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 concise: two sentences with the main action first, then side effects and a caution. Every sentence adds value, with no redundancy or fluff. It is front-loaded and efficiently structured.

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 description covers the core action, side effects, and idempotency, which is essential for a creation tool. However, it lacks usage guidance versus sibling tools and does not mention what happens after creation (e.g., how to retrieve the monitor ID), though no output schema exists. Given the tool's complexity and the presence of annotations, it is adequate but not fully complete.

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?

The input schema has 100% description coverage for all six parameters, so each is already documented. The description does not add any additional semantic meaning about the parameters; it only mentions the API key in the first sentence, which is redundant with the schema. Since coverage is high, the baseline of 3 applies.

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 states the verb and resource: 'Create a monitor', and adds context about persistent state and baseline check. It does not explicitly distinguish from sibling tools like fluxproof_check_now or fluxproof_preflight, but the action is unambiguous and specific enough that an agent can infer the purpose.

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?

No explicit guidance is given on when to use this tool versus alternatives. The only usage-related note is a caution about retrying, which pertains to behavior rather than selection. There is no mention of prerequisites, conditions, or exclusions that would help an agent choose this over sibling tools.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the term 'recent' and 'evidence receipts,' which clarifies the data scope but does not disclose additional behaviors like pagination, ordering, or response format. With annotations present, this modest addition earns a 3.

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 a single, front-loaded sentence with zero wasted words. It immediately states the action and object, making it easy to scan.

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 read-only listing tool with three fully documented parameters and clear annotations, the description is nearly complete. It lacks explicit mention of the return format, but since there is no output schema and the action is straightforward, this is a minor gap. The monitor-scoping is implied by the monitor_id parameter description.

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 description coverage is 100%, so all three parameters (limit, api_key, monitor_id) are fully documented. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.

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 states a specific verb (list) and resource (recent evidence receipts) for a monitor, which distinguishes it from sibling tools like check_now, create_monitor, offer, and preflight. It accurately captures the tool's function without ambiguity.

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 provides no guidance on when to use this tool versus the siblings. It does not mention alternatives, exclusions, or prerequisites beyond the basic purpose. An agent must infer from the name and schema when to call it.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds meaningful behavioral context: it says 'without charging' and clarifies that 'A returned offer is not purchase authorization.' This goes beyond the annotations by specifying that no charge occurs and that the return is not a binding purchase, which is valuable for an agent deciding to call this tool.

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 concise and front-loaded with the core purpose. The first sentence states the function clearly. The second sentence provides usage context and a critical caveat. The empty 'Example: {}' is a minor structural flaw, but overall the description is efficient with no wasted words.

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?

Given there are no parameters, no output schema, and annotations cover safety, the description covers the essential points: what it returns, when to use it, and a key caveat about authorization. It doesn't specify the exact return format, but for an informational tool like this, the description is sufficiently complete for an agent 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?

The tool has zero parameters, so the schema is fully covered (100%). The baseline for 0 parameters is 4, and the description doesn't need to explain parameters. It adds no parameter-specific meaning, but there's nothing to add, so the baseline applies.

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 states the tool returns free and paid boundaries and purchase routes, with the specific verb 'Return'. It distinguishes itself from siblings by focusing on offering information about plans and routes, not checking or creating. The phrase 'without charging' adds clarity. However, it could be more explicit about what 'boundaries' means, and the empty example is a minor flaw.

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 gives explicit context on when to use the tool: 'Read this for the free daily plan, $9 paid pass, human checkout and agent payment route.' This tells the agent exactly what scenarios this tool serves. It doesn't mention alternatives or exclusions, but the context is clear enough for an agent to select it over siblings like fluxproof_check_now or fluxproof_preflight.

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?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful behavior beyond that: it fetches a remote URL, returns a summary of derived fields, and deliberately excludes page content and payment. This is useful contextual disclosure without contradicting the annotations.

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 two short sentences plus an example. It front-loads the core action and return fields, then adds the usage hint. Every sentence earns its place 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 single-parameter read-only tool with strong annotations, the description covers the purpose, behavior, output fields, constraints, and usage sequence. No output schema is provided, but the listed return fields compensate. An agent can confidently call 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?

Schema description coverage is 100% and the single 'url' parameter is already well described with constraints about public HTTP(S), no sign-in, cookies, or browser rendering. The description largely restates 'public URL' and adds an example, but does not add substantial new meaning beyond the schema.

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 specific verb and resource ('Fetch a public URL') and lists exact return fields: fetchability, size, final URL, title, and content hash. It also distinguishes itself by stating it returns no page content or payment, making its role unique among the sibling tools.

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 'Start here before creating a monitor,' which gives a clear when-to-use signal and implies the tool is a prerequisite to fluxproof_create_monitor. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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