Agent Failure Archive

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It hints at a paid response but does not describe side effects, external charges, data handling, or return behavior. The description is too vague to inform the agent about any consequential 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?

The description is one short sentence, but its brevity is due to under-specification rather than efficiency. It spends its only sentence on price and account details instead of tool purpose, so the conciseness does not add value.

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 parameters, no annotations, and no output schema, the description must explain the tool's purpose and behavior. 'Every case in one response' is not enough to understand what 'archive' does, what input it accepts, or what output the agent should expect.

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 baseline is 4 under the rubric. There is no parameter meaning to add beyond the empty schema, and the description's lack of parameter information is not a significant gap.

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 'Every case in one response. One payment, no subscription, no account.' does not state a verb or resource for the tool. It is a pricing/marketing statement that fails to indicate what 'archive' actually does or how it differs from siblings like 'research' or 'contents'.

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?

There is no guidance on when to use this tool versus the sibling tools. The mention of payment implies a purchase, but no conditions, alternatives, or exclusions are given, leaving the agent with no basis for 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions cost and describes the output content, but it does not state whether the operation is read-only, whether it has side effects, what inputs it requires beyond a claim, or any rate/auth constraints.

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 compact and front-loaded with the cost, and every clause adds meaningful information about the audit's output. It is slightly cryptic, particularly 'what to run,' but has no filler or redundancy.

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 annotations, no output schema, and sparse parameter documentation, the description is not enough for an agent to invoke the tool confidently. It lacks usage conditions, evidence semantics, and any statement about side effects or return structure.

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 0%, so the description must compensate. It references the claim parameter but completely ignores the evidence parameter, and it does not explain expected formats, defaults, or how claim and evidence relate.

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 identifies an audit operation over a claim and enumerates concrete output components: why each tripped check matters, the incident with measured numbers, and what to run. It is specific about the resource and deliverable, though it does not explicitly distinguish itself from siblings by name.

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?

There is no guidance on when to use audit versus siblings like precheck, research, or search. The description says what the tool does but not the conditions or prerequisites that should trigger this tool over alternatives.

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?

No annotations are provided, so the description carries the behavioral burden. It discloses a $0.05 cost and indicates the output is a risk brief based on historical failure modes, which implies a read-only advisory tool. It does not explicitly say it avoids executing the action or describe output format or side effects.

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 one front-loaded sentence plus a cost fragment, with no fluff or redundancy. Each phrase contributes either purpose, timing, or behavioral context.

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 one-parameter tool with no output schema and no annotations, it conveys the key call context: pre-action, irreversible, and failure-based. However, it omits the expected input format and the structure/contents of the returned brief, leaving some inference required.

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 0% schema description coverage, the description must compensate for parameter meaning. It connects the single 'action' parameter to the irreversible action being assessed, but it gives no format, examples, or allowed values, so compensation is partial.

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 defines the tool as a 'Pre-flight risk brief before an irreversible action', drawn from how that class of action actually failed, which communicates its core purpose. It avoids tautology but lacks an explicit verb such as 'generates' or 'returns', and it does not directly distinguish itself from siblings like precheck.

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?

It explicitly states when to use this tool: before an irreversible action. It does not mention exclusions or alternative sibling tools, so it stops short of full when-not/alternatives 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?

With no annotations, the description carries the burden of behavioral disclosure. It usefully states that the tool is free and requires no wallet, and it describes the informational content, but it does not explicitly confirm that the tool is read-only or has no side effects. For a zero-parameter catalog tool, this is largely sufficient but not fully transparent.

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, tightly worded sentence with no filler. It front-loads the most important behavioral fact ('Free, no wallet') and then concisely enumerates what the catalog contains.

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 that this is a zero-parameter tool with an output schema present, the description is mostly complete. It explains the informational categories and the cost/payment angle, but it does not mention how this tool relates to siblings like contents or search, which would strengthen completeness.

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 there is nothing for the description to explain. The description focuses on the tool’s purpose and content, which is appropriate and complete given the empty input 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 identifies the tool as a catalog of archive holdings, paid-tool costs, and payment mechanics. It conveys the resource being described, though it lacks an explicit verb like 'list' or 'show' and does not differentiate itself from the sibling 'contents' tool.

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 no guidance on when to use this tool versus alternatives such as contents, search, or research. It implies a browsing/informational use case through the 'catalog' wording, but there is no explicit context for selection or exclusion.

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?

With no annotations, the description carries the burden and mostly delivers: it discloses that access is free, requires no wallet, returns titles only, and covers the full archive. It does not describe whether 'theme' filters results or whether output is paginated, but the existing output schema reduces the need to explain return shape.

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, all information-dense and front-loaded with the key access trait 'Free, no wallet.' No repetition 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 simple listing tool with an output schema, the description covers cost, access, scope, and decision context well. The only meaningful gap is the undocumented 'theme' parameter, which prevents the definition from being fully self-sufficient.

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 schema has one optional parameter, 'theme', with 0% description coverage, and the description never mentions it. The phrase 'tagged with the trap it illustrates' weakly hints that theme might filter by trap, but this is not explicit, leaving an agent to guess the parameter's meaning and valid values.

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 provides: every case title in the archive, tagged with the trap it illustrates, with bodies excluded. It distinguishes itself from a paid archive and from fuller siblings by emphasizing 'Titles only, no bodies' and 'Free, no wallet.'

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 for when to use this tool: before deciding whether the paid archive is worth a dollar. It does not name alternative sibling tools or when-not-to-use cases, so it stops short of full routing 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?

With no annotations, the description carries the disclosure burden and covers important behavioral traits: it is free, requires no wallet, returns a specific result shape, and implicitly limits itself to basic checks by contrasting what the paid audit tool adds. It omits data-handling/rate-limit details, but nothing about the tool suggests destructive or auth-sensitive effects.

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: the first states cost and core behavior, the second gives usage timing, and the third differentiates the paid sibling. Every sentence earns its place and the most important information is front-loaded.

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 two-parameter tool with an output schema, the description covers the action, the cost, the trigger, and the return content. The main gap is the unexplained optional 'evidence' parameter, which prevents this from being 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?

Schema description coverage is 0%, so the description must compensate; it clarifies that the required 'claim' is a conclusion to be checked, but it never mentions the 'evidence' parameter or how it relates to the checks. With one of two parameters left entirely undocumented in both schema and description, the added meaning is only partial.

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 action ('Check a conclusion'), a defined resource ('nine known ways of fooling yourself'), and the output ('which checks it trips plus the question each one asks'). It also distinguishes itself from the paid 'audit' sibling, so an agent can tell them apart without opening schemas.

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?

It gives an explicit trigger: 'Use it before writing "we found that"'. It also positions the paid audit tool as the richer alternative, implying the conditions under which precheck is sufficient. It does not state a hard when-not-to-use rule, but the context is clear.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state whether the tool returns data, modifies state, triggers an action, or performs a computation. The fragment about 'measurement failures' hints at subject matter but not tool 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?

The text is short, but this is under-specification rather than effective conciseness. '$0.25' is unexplained and the remaining sentence does not earn its place as actionable tool guidance.

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 one optional parameter, no output schema, and no annotations, the description needed to define the tool's purpose, inputs, and returns. It fails to define any of these, leaving an agent with no way to correctly invoke the 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?

Schema description coverage is 0%, and the description never mentions the single parameter 'q'. Neither the schema nor the description explains what q means, how it affects results, or what values are valid.

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 is a noun phrase—'The 107 measurement failures from an eight-month attempt...'—with no verb or stated operation. It does not say what the tool does, what resource it acts on, or how it is distinguished from siblings such as search or catalog.

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?

There is no indication of when to use this tool versus alternatives like archive, brief, or sample. No context, conditions, or exclusions are provided.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the cost/profile ('Free, no wallet') and the scope of output ('two complete post-mortems from the archive'). However, it does not say whether the operation is read-only or whether it has any side effects, which is relevant for a tool with no annotation coverage.

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 extremely short and front-loads the most important information: free access and no wallet requirement. There is no filler, though writing it as a complete sentence with an explicit verb would improve structure.

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 tool with an output schema, the description is nearly complete: it conveys cost, authentication expectations, item count, and source. The main gap is that it doesn't clarify how this sample relates to or differs from sibling tools, but the simple interface keeps this from being a serious omission.

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 fully covers parameter semantics. The description does not need to explain parameters, and it appropriately avoids inventing any. Baseline 4 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 identifies the resource ('two complete post-mortems from the archive') and a distinguishing condition ('Free, no wallet'), which makes the tool's purpose reasonably clear. However, it lacks an explicit action verb like 'retrieves' or 'provides', relying on the tool name 'sample' to complete the meaning.

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?

There is no guidance on when to use this tool versus siblings like search, archive, or precheck. The phrase 'Free, no wallet' implies a low-cost/preview use case, but the description never states when this sample should be requested or when another tool should be preferred.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal the return shape (three post-mortems, each with root cause, fix, prevention rule), but it omits safety/read-only signals, no-match behavior, and meaning of the leading '$0.01' prefix. No contradiction exists.

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 compact sentence that front-loads the result count and resource type. The '$0.01.' prefix is ambiguous and may not earn its place, but the rest is efficient and focused.

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 one-parameter search tool, the description conveys the main outcome and key fields, but it leaves input semantics, edge cases, and exact output formatting to inference. With no output schema, an agent would benefit from an example or more explicit return structure.

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 schema has one required string parameter q with no description and 0% schema coverage. The description partially compensates by indicating that results are 'matching a symptom,' implying q represents the symptom, but it never explicitly defines q or explains expected input format.

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 concrete output: three real agent post-mortems matching a symptom, each with root cause, fix, and prevention rule. The tool name 'search' plus 'matching a symptom' clarifies the action, and the post-mortem focus distinguishes it from 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?

There is no guidance about when to use this tool versus siblings like research, catalog, or sample. The description only implies that the user should supply a symptom, but it never states exclusions, alternatives, or required context.

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