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

No annotations are supplied, so the description carries the full behavioral burden, and it does substantial work: it discloses that the tool will only use verified pack facts, that it may refuse ('cite-or-refuse'), that it asks clarifying questions, and that an assessment is only emitted 'when it passes self-verification'. That tells the agent to expect partial or refused outputs and per-fact citations. It omits any mention of latency, cost, or permission requirements, and never explains what a 'gate' actually is.

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 sentences, front-loaded with the action, with no filler or repetition. It is dense and information-rich, but the compressed jargon ('gates', 'self-verification') costs a little clarity for the space saved.

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 no annotations and no output schema, the description supplies an unusually good picture of the return value: gates with per-fact citations, open questions, and a conditional assessment. What is missing is the failure mode (what a refused or failed-verification response looks like) and any pointer to counsel_domains for the optional domain argument.

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 both parameters are already documented and the baseline is 3. The description's 'describe a real situation' loosely reinforces the narrative parameter's intent but adds no format, length, or detail-level guidance, and it never mentions the optional domain parameter or the auto-detection behavior that the schema already covers.

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 concrete verb and resource: 'Ask FactStable Counsel' about 'a real situation', which then digests it and derives 'possible outcome pathways using ONLY verified pack facts'. That is clearly distinct from the sibling get_fact/list_facts/changes tools, which retrieve facts rather than reason over a narrative. It stops short of 5 because internal jargon ('gates', 'cite-or-refuse', 'self-verification') is not defined, so the exact product of the call is slightly opaque.

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: you call it when you have a 'real situation' to be analyzed, as opposed to looking up a single fact. There is no explicit when-not guidance, no mention of counsel_domains as the way to discover the domain value, and no statement about what to do if the tool refuses or fails verification. The agent must infer routing from the sibling names alone.

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