fcs_withdrawal

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

With no annotations provided, the description carries the full behavioral burden, and it does useful work: it discloses that unset outcomes remain undetermined and never collapse to a negative, and it explicitly flags the asymmetry that a favourable human grain outcome does not corroborate M2. These are non-obvious interpretive rules beyond what a schema could convey. It stops short of stating side effects or read-only guarantees, but for an evaluation tool the disclosed rules are substantial.

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: two sentences, no filler, and the core evaluation purpose is front-loaded. The density of jargon makes it less accessible, but every sentence contributes either the core behavior or critical caveats.

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?

This is a moderately complex tool with 8 parameters, no annotations, and no output schema, yet the description does not explain the output shape, how to interpret the result beyond broad categories, or which parameter drives the M2 asymmetry. It gives the conceptual model but not enough operational detail for an agent to invoke it correctly with specific inputs. The missing parameter mapping and absent use-case guidance leave clear gaps.

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 there are eight undocumented boolean/null parameters, so the description must compensate by explaining their meaning. It provides general outcome semantics and one indirect reference to a 'human grain outcome', but it never maps parameter names like bridgeCovariation or fieldBeyondFiringInHumans to the concepts being evaluated. The agent is left to guess which parameter corresponds to which thesis.

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 operation ('Evaluate the protective belt against experimental outcomes') and the concrete questions it answers: which theses are withdrawn, stand, or are undetermined. It is not a tautology and reads as distinct from sibling tools like fcs_report or fcs_taxonomy. However, terms like 'protective belt' and 'M2' rely on domain jargon, so a general-purpose agent would need more framing to fully understand the resource.

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 call this tool versus similar fcs_* siblings such as fcs_stratify, fcs_compare, or fcs_conformance. The description implies a use case (after experimental outcomes exist) but gives no conditions, prerequisites, or exclusions. This is a significant gap given the large sibling list.

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