fluxproof_offerInspect FluxProof's free daily plan and $9 pass limits, human checkout link, and agent payment route without being charged.
Return free and paid boundaries and purchase routes without charging. Returns the free daily plan, the $9 paid pass, the human checkout link and the agent payment route. Example: {}. Reading the offer charges nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuinely non-structured context: this call cannot trigger a charge, and it exposes both a human checkout link and a separate agent payment route. That payment-route detail is behavioral information not available in 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 content list is front-loaded and useful, but the no-charge point is repeated twice ('without charging' and 'Reading the offer charges nothing'), and 'Example: {}' is largely filler for a no-argument tool. Mildly redundant rather than tight.
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 must convey what comes back, and it does so by enumerating the four returned items. With annotations covering safety and no parameters to document, an agent has enough to call this correctly; only the exact response shape remains unstated, which is acceptable here.
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 zero parameters and 100% schema description coverage, the baseline is 4. The 'Example: {}' notation reinforces that the call takes no arguments, adding a little confirmation but no parameter semantics beyond what the empty schema already shows.
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), then enumerates the concrete items returned (free daily plan, $9 paid pass, checkout link, agent payment route). That is far more specific than a tautology. It does not explicitly distinguish itself from siblings, but the pricing/offer domain is clearly unique among them.
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: reading the offer is described as a no-cost way to inspect plans before purchasing, which suggests when to call it. However, there is no explicit comparison to alternatives such as fluxproof_get_free_key, nor a stated condition for choosing this over them. Implied usage, minimum viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.