MCPFax Reliability

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds crucial context beyond annotations: the grade is not a calibrated probability, not a security audit, coverage is young, and there is a cost per call. This is strong behavioral disclosure.

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 four sentences, but each sentence serves a distinct purpose: output components, usage scenario, limitations/caveats, and cost. It's front-loaded with the most essential information and avoids redundancy. Slightly longer than the top-tier two-sentence example, but still efficient.

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 a single-parameter schema and no output schema, the description thoroughly explains return values (grade, score, subscores, confidence, flags, evidence, archive_coverage) as well as limitations and pricing. It is complete enough for an agent to invoke and interpret results 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% with a detailed explanation of the 'endpoint' parameter, including format examples. The tool description adds no extra parameter semantics, but the schema fully compensates, so a 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 the tool's output: a creditworthiness grade with letter grade, numeric score, subscores, confidence, flags, and evidence. It also gives a specific use case ('before trusting or paying an unfamiliar endpoint'), which distinguishes it from risk-assessment siblings by focusing on credit risk.

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 states when to use the tool ('before trusting or paying an unfamiliar endpoint') and warns about coverage limitations (most listings grade NR, payer-concentration risk not rated). It doesn't name alternative tools, but the usage context is clear and actionable.

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 goes beyond annotations by disclosing cost ($0.01 USDC per call), the limitation that inflow is not proven to be x402 sales revenue, and the scanned_days caveat for trend windows. These are important behavioral traits not captured by the readOnlyHint, idempotentHint, or destructiveHint. 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?

The description is efficiently structured: it starts with purpose, then usage, caveats, and cost. Each sentence earns its place and provides distinct value without redundancy. The length is appropriate for the tool's complexity.

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 no output schema, the description sufficiently conveys the return signals, including the scanned_days field and per-window flags. It also covers limitations and cost, making it complete for an agent to invoke and interpret the result.

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 fully describes the only parameter with format and examples, so baseline is 3. The description adds little about the parameter itself beyond 'one listing,' which does not materially improve on 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 clearly states it observes on-chain revenue signals for one listing and lists specific metrics (USDC inflow, payers, modal transfer size, trends, percentile), distinguishing it from sibling tools like credit score or wallet authenticity. The verb 'estimate' and resource 'endpoint revenue' are explicit.

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 a clear use case: 'Use this to size a seller's real traction.' It does not explicitly name alternatives or exclusions, but the unique focus on revenue signals differentiates it from siblings. The caveats about data interpretation also guide when to trust the result.

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 significant behavioral details beyond the readOnlyHint/idempotentHint annotations: billing per call, watermark semantics (last observed date, not current clock), the not_observed behavior with no verdict, verified-unchanged as a real billed answer, and archive span caveat. 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?

The description is dense but every sentence carries information. It is front-loaded with purpose, then usage, then behavioral caveats. Slightly long, but no waste; could arguably be split into two paragraphs for readability, but the content justifies the length.

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?

Despite no output schema, the description explains what is returned (changes after `since` plus fresh watermark, verified-unchanged with date, not_observed list). It covers cost, coverage span, and uses clear examples. For the tool's complexity, this 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 coverage is 100%, so baseline is 3, but the description adds crucial meaning: explains `since` is the watermark from the previous call and can be omitted on first call, clarifies subjects is a comma-separated list (max 50), and clarifies the semantics of the watermark (last observed date). This goes well beyond the schema's field descriptions.

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 uses a specific verb and resource: it tells you 'what changed under an x402 endpoint or MCP server you have ALREADY integrated' and enumerates concrete change types (payTo rotations, price, asset, network, terms, tool-schema). It explicitly distinguishes from siblings by stating it is not a discovery tool and will not help choose a server.

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?

Explicitly states when to use: to check whether an already-integrated server still matches. Explicitly names an alternative use ('This is not a discovery tool') and gives operational guidance (pass up to 50 subjects, use the `since` watermark from the last call).

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 (readOnlyHint, openWorldHint, etc.), the description discloses important behavioral traits: screening signals are withheld with 'not_rated' until a coverage floor is met (14 days, 20 payments), measured facts are always returned without intent inference, and the per-call cost ($0.002 USDC via x402 on Base). This adds meaningful transparency about gating and monetization.

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 three sentences, front-loaded with the core purpose, followed by usage guidance, then gating behavior and cost. Every sentence carries valuable information with no redundancy or 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 tool with no output schema, the description adequately covers the return categories (distinct services, spend, contract/EOA, screening signals), explains the 'not_rated' status behavior, and mentions cost. It is complete enough for an agent to invoke and interpret results 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% and the parameter description in the schema is clear and complete. The description adds marginal semantic context by referring to the 'paying wallet' and 'paying you,' but does not enrich the parameter's technical 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 clearly states the tool's purpose: a know-your-agent profile for a paying wallet, listing specific metrics (distinct services, total spend, contract vs EOA, screening signals). This distinguishes it from sibling tools like wallet_authenticity or endpoint_credit_score by focusing on the payer profile.

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 'Use this to vet a counterparty that is paying you,' providing clear context for when to use it. It does not explicitly exclude alternatives or name sibling tools, but the usage context is strong enough to guide selection.

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, destructiveHint=false, but the description adds significant behavioral context beyond that: the feed cannot return events before the archive started, it reports coverage.archive_since and rating_actions_recorded, and it costs $0.001 USDC per call via x402. These are valuable operational details with no contradiction.

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 four sentences, each contributing essential info: what the feed is, event types, when to use it, a key limitation, and cost. No filler or redundancy, and it is front-loaded with the core purpose.

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 one optional parameter and no output schema, the description covers the main aspects: purpose, event types, usage guidance, limitation, response fields, and cost. It does not detail the exact structure of each event, but for a feed with these listed event types it is largely complete. A bit more about return format 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?

The only parameter 'since' has 100% schema description coverage, with the schema explaining format, default, and archive behavior. The tool description mentions 'since a date' but adds no extra semantics beyond the schema. Per rubric, high schema coverage yields baseline 3.

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 what the tool does: provides a chronological feed of rating actions with specific event types (grade upgrades/downgrades, payTo wallet changes, listing removals, returns). It distinguishes from siblings by emphasizing monitoring a portfolio for adverse changes rather than re-scoring each one, which separates it from scoring/estimation 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 gives an explicit use case: 'Use this to monitor a portfolio of endpoints for adverse changes rather than re-scoring each one.' This provides clear context and a rationale, though it does not explicitly name alternative tools or say when not to use it. The limitation about archive start is also useful guidance.

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 and destructiveHint=false, but the description adds substantial behavioral context: the probe is unpaid and bounded (~2.2s cap), the return splits into LIVE and HISTORICAL parts, the verdict is ADVISORY and not a warranty, UNKNOWN is a legitimate answer with specific conditions, and being charged nothing when the target is unreachable and unobserved. It also states the cost and payment rail ($0.002 USDC via x402 on Base). This goes far beyond annotation hints.

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?

Though the description is long, it is structured with clear headings ('WHEN THIS PAYS FOR ITSELF', 'WHEN IT DOES NOT', 'Returns two halves') and densely packed with actionable information. Every sentence contributes to understanding the tool's purpose, cost, limits, and return value. The front-loaded purpose sentence immediately clarifies the tool's role.

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 explaining return values. It does so thoroughly by detailing the LIVE half (reachability, HTTP status, latency, MCP initialize probe, price/payTo) and the HISTORICAL half (reliability, payTo changes, price changes, tool-schema changes, first-seen date, credit grade). It also covers edge cases (UNKNOWN semantics, freshness via max_age_seconds, and charging nothing when unobserved and unreachable). For a tool with this complexity, the description 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?

The input schema has 100% coverage, properly describing each parameter. The description adds functional meaning on top: expected_price, expected_payto, and expected_schema_hash are compared 'old to new' with a date of first observed change, and probe_method is restricted to side-effect-free methods. While the schema already documents the parameters, the description clarifies how they are used together in the comparison logic.

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 clear verb and resource: 'Check that an endpoint is live and that its terms have changed, BEFORE you send it an expensive request.' It distinguishes this tool from sibling tools focused on credit scores, revenue estimates, drift, etc., by emphasizing preflight liveness and terms verification before a consequential call.

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 states when to use it ('Buy it before a consequential call — expensive inference, a purchase, a state-changing action') and when not ('not before a cheap one'), even providing a quantitative cost-benefit example. It also contrasts with sibling tools by focusing on preflight checks rather than ongoing monitoring or credit evaluation.

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, but the description adds significant behavioral context beyond these: the 14-day/20-payment threshold before a haircut is issued, the null-with-'not_rated' status, the $0.01 USDC cost via x402 on Base, and the caveat that concentration is not proof of common control. This thoroughly explains edge-case behavior and costs.

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 information-dense yet well-structured. The first sentence lists the key outputs, the second gives the use case, the third explains the coverage threshold and null behavior, the fourth adds an interpretive caveat, and the fifth states the cost. 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?

With no output schema, the description carries the full burden of explaining return values and behavioral nuance. It names all essential output concepts, the condition for rated vs. not_rated, the cost, and the correct interpretation of concentration. This is more than sufficient for an agent to decide when to use the tool and what to expect from 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?

Schema coverage is 100%: the single wallet parameter is fully described with a pattern and example. The description calls it a 'receiving wallet,' which duplicates the schema's 'receiving EVM wallet address.' No additional parameter semantics are added beyond what the schema already provides, so the baseline score 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 uses a specific verb and resource: 'Payer-concentration and wash-risk assessment for a receiving wallet.' It clearly lists the outputs (concentration, coverage, haircut, listings, USDC inflow) and explicitly frames its purpose as judging whether revenue reflects real independent demand, distinguishing it from sibling tools like revenue_estimate or credit_score.

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 a clear use case: 'Use this to judge whether a seller's apparent revenue reflects real independent demand.' It tells the agent when to invoke the tool, though it does not explicitly name alternative tools or state when not to use it. This is clear context but not exhaustive exclusions.

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