Count integer partitions of a non-negative integer n, optionally constrained by maximum part size or exact number of parts, to solve combinatorial counting problems.
Count integer partitions of n with optional max part size and part count constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| n | Yes | Non-negative integer to partition (0-10000) | |
| max_part | No | Maximum part size | |
| num_parts | No | Exact number of parts |
Changes observed during successful MCP inspections.
v0.1.11Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that: it doesn't note that results grow extremely large (p(10000) is astronomical) or how such values are returned, and doesn't mention the 0-10000 bound or performance characteristics.
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?
A single front-loaded sentence that names the operation, the primary argument, and the two optional constraints with zero filler. Nothing could be removed without losing 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?
For a simple, pure math tool with full schema coverage and safety annotations, the description is nearly sufficient. The only real gap is that with no output schema the description never characterizes the result (a single count, potentially a very large integer, and how that is represented).
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 all three parameters (n with range 0-10000, max_part, num_parts) are already documented in the schema. The description restates the semantics of max_part and num_parts at a high level but adds no format, boundary, or interaction detail beyond what the schema provides. Baseline 3 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?
States a specific verb ('Count') and a precise mathematical resource ('integer partitions of n'), plus the two optional constraint dimensions. An agent can distinguish it from siblings like combination_calc or partition-adjacent tools, though it never explicitly names a sibling or contrast case.
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 scenario is implied by the domain vocabulary ('integer partitions of n with optional max part size and part count constraints'), so an agent knows what the tool is for. There is no explicit when-to-use/when-not guidance and no mention of which sibling to prefer for related combinatorial counts (e.g. permutation_calc, combination_calc).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.