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?

Beyond the annotations (which already flag readOnly=false and idempotent=false), the description discloses that the call creates persistent state, performs a baseline check, and consumes quota — meaningful operational context. The non-idempotent statement is somewhat redundant with idempotentHint=false, and it omits any note on rate limits or error behavior, keeping it below a 5.

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 tight sentences with zero filler; the API-key prerequisite, the side effects, and the idempotency caveat are all front-loaded and immediately actionable.

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 6-parameter mutation tool with no output schema, the description covers creation semantics, side effects, and quota cost well. The one gap is that it never indicates what is returned (e.g. a monitor identifier) that the agent would need for follow-up calls, which is more relevant given no output schema exists.

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 the schema already documents all six parameters with detail (URL constraints, term limits, interval minimums). The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline of 3 when the schema does the heavy lifting.

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 ('Create a monitor') and reinforces it with the title's 'Start watching a page', making the core action unambiguous. It does not explicitly differentiate itself from siblings like fluxproof_check_now or fluxproof_preflight, so it falls short of a 5.

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 a prerequisite (a buyer-owned API key) but never states when to choose this tool over fluxproof_check_now, fluxproof_preflight, or fluxproof_get_free_key. There is no explicit when-to-use or when-not-to-use guidance, leaving the agent to infer selection from sibling names 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 only cover the generic flags (readOnlyHint=false, idempotentHint=false). The description adds genuinely useful behavior beyond them: the key is returned only once, it is a secret credential, and there is a per-network monthly issuance limit. It does not say what the response payload looks like or how to use the key afterward, keeping it short of a 5.

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?

One tight sentence, front-loaded with the verb and resource, with no filler. The comma-chained clauses ('one page, checked daily, for 30 days, no card') are dense and could be structured slightly more legibly, which keeps it from a 5.

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 zero-parameter, no-output-schema provisioning call, the description covers the essentials: what is created, the free-tier terms, the rate limit, and the one-time secret nature of the credential. Only minor gaps remain (credential format, whether it binds to an account).

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 takes zero parameters, so there is no parameter semantics to document; the baseline for a parameterless tool is 4. The description correctly does not invent or discuss inputs.

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 ('Create a free FluxProof API key') and immediately qualifies scope with concrete constraints (one page, daily checks, 30 days). It is easy to distinguish from siblings like fluxproof_create_monitor or fluxproof_check_now, though it never names an alternative explicitly.

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 through constraints: 'no card' and 'one per network per month' tell the agent when the call will succeed or fail. However, there is no explicit when-to-use or routing versus the sibling tools, so the agent must infer that this is the onboarding/credential step.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral facts beyond the annotations: no payment is charged, no page content is returned, and the fetch happens exactly once. It stops short of describing rate limits or error 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?

Three short sentences, front-loaded with the action and its outputs, followed by mechanics and an example. The JSON example largely duplicates the schema's own example, which is minor redundancy rather than bloat.

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 correctly carries the burden of naming the returned fields (fetchability, size, final URL, title, content hash). For a one-parameter read-only tool with full annotation coverage, that is nearly everything an agent needs; only error/failure semantics are absent.

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% and the single 'url' property already carries a detailed description (full page address, not a search phrase, no sign-in/cookies/rendering/private networks). The description only restates the one-URL constraint and repeats an example URL already present in the schema, so it adds little beyond structured data. 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 ('Fetch a public URL') and enumerates the return values (fetchability, size, final URL, title, content hash). It implicitly separates itself from write-side siblings by noting 'nothing is created or charged', but never names create_monitor or check_now directly, so sibling differentiation is left to inference.

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 'preflight' framing plus 'says whether it can watch it' and 'nothing is created or charged' implies this is a free pre-check run before creating a monitor, but no alternative is named and no explicit when-not condition is given. Usage is implied rather than stated.

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