FluxProof

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, but the description adds genuinely new behavioral context: quota consumption, persistence of a receipt, and possible webhook delivery as a side effect. This is meaningful added value beyond the structured hints, though it stops short of describing authorization or failure behavior.

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?

Two compact sentences, front-loaded with the action and result, followed by the cost/side-effect disclosure. Every clause earns its place and nothing is repeated from the title.

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 side-effecting, non-idempotent action tool with no output schema, the description covers the success artifact ('change receipt'), the cost (quota), and the side effects (receipt stored, webhook fired). The remaining gap is the absence of any error or authorization expectation, but the core operational picture is 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?

Schema description coverage is 100%, with both api_key and monitor_id documented in the schema, including the binding constraint that the monitor must belong to the calling key. The description adds nothing about parameter format or constraints, so 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 states a specific verb and resource — run a monitor and return a source- and hash-bound change receipt — which is far more precise than the title alone. It implicitly distinguishes itself from read-oriented siblings like fluxproof_list_changes by declaring it is 'not an idempotent read,' though it never names an alternative tool to route to.

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?

Usage is implied by the effect disclosure ('consumes check quota, stores a receipt, may deliver a webhook'), which tells an agent the cost of calling it. However, there is no explicit when-to-use versus when-not-to-use guidance, and no alternative such as fluxproof_list_changes is named for the case where the agent only wants existing results.

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?

Adds real context beyond the annotations: it performs a baseline check, consumes quota, and creates persistent state. 'Not idempotent' merely restates idempotentHint=false, so it earns no extra credit, and it says nothing about failure behavior for an invalid or unreachable URL.

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 filler, and the operative facts (credential, persistent state, quota cost, non-idempotency) are front-loaded. Each sentence carries distinct information.

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 an 8-parameter, nested-object creation tool with no output schema, the definition never says what is returned or how the created monitor is subsequently referenced by check_now, list_changes, or offer. That identifier gap is significant for a state-creating tool, though the input side is fully covered by the schema.

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 every parameter including the nested part and alert_when objects is already documented with constraints. The description only echoes the API-key parameter, adding no semantics beyond the schema; baseline 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?

States a specific verb and resource ('Create a monitor') plus the key prerequisite ('buyer-owned FluxProof API key'), so the agent knows exactly what the tool does. However, it never distinguishes itself from siblings like fluxproof_preflight or fluxproof_get_free_key, which an agent would plausibly need 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?

Usage context is implied rather than stated: mentioning a buyer-owned API key and quota consumption signals this is a billable, credentialed operation. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as checking a URL with fluxproof_preflight before committing to a persistent monitor.

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 signal a non-read-only, non-idempotent, non-destructive write, so the description doesn't need to restate that. It adds genuinely non-obvious behavior: a per-IP-per-month throttling rule and the fact that the credential is returned once and is secret, which changes how an agent must handle the response. It stops short of explaining what happens on a throttled attempt (error shape, wait guidance).

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?

Two compact sentences with zero filler, front-loading the action and then the terms. Every clause carries decision-relevant information: limits, expiry, no card, one-time secret return.

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?

With no input parameters and no output schema, the description covers the essentials, including the critical one-time-return behavior that an output schema would otherwise have to document. It omits how the key is used afterward (header format, auth scheme), a minor gap for a zero-arg provisioning tool.

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, so the baseline is 4; nothing in the schema needs explaining. The description correctly implies the tool takes no input, and the constraints it lists (IP, monthly window) are server-derived rather than arguments.

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?

States a specific verb and resource ("Create a free FluxProof API key") and immediately qualifies it with the entitlement: one page, checked daily, 30 days, no card. It is plainly the key-provisioning tool, distinct from siblings like fluxproof_create_monitor or fluxproof_offer.

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 conveys when this is relevant by describing the free-tier offering and its limits, which implies you call it before any authenticated work. However, it never explicitly says to call this first, nor does it point to the alternatives (e.g. fluxproof_preflight or fluxproof_offer) or state what to do if you already hold a key.

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, destructiveHint=false, and a closed-world scope, so safety is fully covered by structured data. The description adds only the word 'recent', giving no ordering, pagination, or truncation behavior, and it does not mention that history depth is plan-gated (that constraint lives only in the 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?

A single front-loaded sentence with no filler, which is structurally sound. It is arguably too terse for the amount of unexplained domain vocabulary, but nothing is wasted.

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?

There is no output schema, so the description carries the burden of describing what is returned, yet it never says what an 'evidence receipt' contains, how results are ordered, or how the limit interacts with a monitor's history. For a tool whose entire value is the returned list, this leaves a significant gap.

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 monitor_id, limit (with its default of 20 and plan restriction), and api_key are all documented in the schema. The description adds no extra meaning about these parameters, so the baseline 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?

States a specific verb ('List') and resource ('evidence receipts for a monitor'), so an agent knows it retrieves recorded history for a given monitor. However, the name says 'changes' while the description says 'receipts', and neither the term 'evidence receipt' nor its relationship to a 'change' is explained. No sibling tool does the same thing, so differentiation is not a practical problem.

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 when-to-use guidance, no conditions, and no mention of the alternatives an agent might reach for (e.g., fluxproof_check_now to produce a fresh check versus this tool to read past ones). The agent must infer that this is the read-history counterpart from the name alone.

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 establish readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds real value beyond that by disclosing that reading costs nothing, the exact payment terms (30 days paid once, monthly through human checkout, cancel any time), and that both a human checkout link and an agent payment route are returned.

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 core constraint ('without charging') is front-loaded in the first sentence, and the pricing detail is dense but each clause conveys distinct facts (free plan, one-time $9 pass, optional monthly $9, cancel terms). The 'Example: {}' fragment is filler that could be dropped.

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?

With no output schema, the description carries the burden of describing returns, and it does so adequately: free daily plan, $9 pass, human checkout link, and agent payment route. Minor gaps remain, such as the format of the returned link/route fields, but an agent has enough to call and interpret it.

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, so the baseline is 4. The 'Example: {}' is a minor confirmation that the tool takes no arguments, but it adds nothing beyond what the empty properties object and additionalProperties=false already 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 names a specific verb ('Return') and resource ('free and paid boundaries and purchase routes'), and the pricing/pass detail makes it easy to distinguish from pricing-unrelated siblings like fluxproof_check_now or fluxproof_list_changes. It stops short of explicitly contrasting itself with the closest sibling, fluxproof_get_free_key, which is about obtaining a key rather than viewing plans.

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?

Usage is implied rather than stated: an agent infers it should call this when it needs pricing or a purchase route, and the phrase 'Reading the offer charges nothing' implies it is safe to call speculatively. There is no explicit when-not condition and no pointer to which sibling to use instead for related tasks.

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 readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered; the description adds genuinely new facts — the page is fetched exactly once, no page content is returned, and no charge or resource creation occurs. That goes beyond the annotations, though rate limits or failure modes (what 'unfetchable' looks like) are not described.

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 core capability and its exclusions are front-loaded in the first sentence, with supporting detail after. The inline JSON example is slightly redundant with a 100%-covered one-parameter schema, which keeps it from a perfect score, but overall it is compact and well ordered.

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?

There is no output schema, so the description carries the return-value burden itself and does so by enumerating all five returned fields. Combined with the fetch-once and no-charge guarantees, an agent has everything needed to invoke this correctly for a single-URL, read-only tool.

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?

With one parameter at 100% schema coverage, the schema already documents the URL fully, including the bare-domain allowance and exclusions for search phrases and private networks. The description's example adds a small confirming illustration but no meaning not already in the structured field, so the baseline 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 states a specific verb and resource — fetch one public URL and return fetchability, size, final URL, title, and content hash — which is far more informative than the title's generic 'check a public page'. It also makes clear what it does not do (no page content, no payment, nothing created), which implicitly distinguishes it from monitor-creation siblings, but it never names a sibling tool outright.

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?

Usage is only implied: 'preflight' plus 'nothing is created or charged' hints this is a trial/lookup step before using fluxproof_create_monitor or fluxproof_check_now, but the description never says when to pick this over those tools. No explicit exclusions or prerequisites are given beyond the input constraint about public pages.

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