add_assertion_tool

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 mentions that assertions must be grounded by evidence, but does not disclose side effects (e.g., how the assertion is added to the theory), whether existing assertions are overwritten, or any permission/validation requirements. This is a significant gap for a mutation tool.

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 long, front-loaded with the core purpose, and every sentence adds substantive value (what it does, what assertions are, the grounding requirement). There is 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?

Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It does not explain the return value, how to obtain evidenceId, what happens if the assertion conflicts with existing theory, or how confidence is used. The description covers the 'what' but not the 'how' or 'when' details.

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%, yet the description only clarifies that assertions are 'typed beliefs' (hinting at assertionType) and must be grounded by evidence (relevant to evidenceId). It does not explain content, regionId, confidence, or the exact format of evidenceId. With six parameters and no schema descriptions, the description fails to adequately compensate.

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 specific action ('Add an assertion'), the resource ('synthesis theory'), and the key requirement of evidence grounding. It distinguishes itself from sibling tools like list_assertions_tool and contract_assertion_tool by focusing on adding a grounded assertion.

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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The evidence grounding requirement implies a precondition, but there is no clear guidance on selecting this tool over related tools like store_evidence_tool or revise_theory_tool.

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