factorial

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool calculates, without mentioning computational limits (factorial grows rapidly), error handling for negative inputs (though schema allows negative integers), performance characteristics, or return format. For a mathematical function with potential overflow issues, this is inadequate behavioral transparency.

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, efficient sentence in Chinese that directly states the tool's purpose. There's zero wasted language, no redundant information, and it's appropriately sized for a simple mathematical function. The structure is front-loaded with the essential information.

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 a mathematical function with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address important contextual elements like return values (integer likely, but possibly with overflow), error conditions, computational limitations for large n, or mathematical definition (including 0! = 1). For even a simple tool, more context would help the agent use it 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 0%, so the description must compensate. It adds some meaning by specifying 'non-negative integers' which clarifies the intended domain beyond the schema's broad integer range (-2147483648 to 2147483647). However, it doesn't explain what 'n' represents (input number), valid ranges for practical computation, or handling of edge cases like 0! = 1. With one undocumented parameter, this partial compensation earns a 2.

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 '计算非负整数的阶乘' (calculates the factorial of a non-negative integer) clearly states the verb (calculates) and resource (factorial), and specifies the domain (non-negative integers). It distinguishes from siblings like 'product' or 'multiply' by focusing on factorial specifically. However, it doesn't explicitly differentiate from mathematical siblings like 'combination' or 'permutation' which also involve factorials.

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 no guidance on when to use this tool versus alternatives. It doesn't mention when factorial calculations are appropriate compared to other mathematical operations in the sibling list, nor does it provide any context about prerequisites, constraints, or typical use cases. The agent must infer usage purely from the mathematical function name.

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