Averages, spread, chi-square, regression, primes, factorials, probability, areas and distances
Scored across 22 tools
Most tools target clearly distinct operations (factorial vs is_prime vs fibonacci), and descriptions clarify the intended scope. Minor overlap exists between calculate_area and polygon_area_shoelace, and between euclidean_distance and calculate_distance (2D plane vs geographic Haversine), which could cause occasional misselection.
The set mixes a 'calculate_' prefix (calculate_area, calculate_median, calculate_distance) with bare nouns (average, factorial, cosine_similarity) and other verb styles (create_histogram, solve_quadratic, is_prime). Each name is readable on its own, but there is no single predictable convention across the set.
22 tools is on the heavy side for a general maths/statistics utility server, with many small one-off calculators (clock angle, dice probability, is_power_of_two) that add surface area without a unifying workflow. It is not unreasonable, but it sits in the borderline 16-25 range.
Coverage spans descriptive stats, geometry, number theory, probability, and regression, but there are notable gaps for a 'maths and statistics' domain: no mode, variance, percentile/quantile, correlation, sum/min/max, or basic arithmetic operations. Agents would hit dead ends on common requests despite the breadth.
Calculates the arithmetic mean (average) of a list of numbers by summing all values and dividing by the count. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | No | array, required, list of numeric values, no unit, no default |
Does 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 covered. The description adds only a 'cost: 1 credit' billing note, which is genuinely useful, but says nothing about edge behavior an agent needs here: empty list handling, non-numeric strings, the output format, or whether the string input form is comma-separated.
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?
One sentence plus a cost tag, with the core purpose front-loaded and no redundant wording. Every clause carries 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 one-parameter, annotation-covered, no-output-schema tool, the description is close to sufficient. The remaining gap is input-shape handling (how a string of numbers is parsed) and empty-input behavior.
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 coverage is 100%, so the single 'numbers' parameter is already documented including requiredness and unit. The description restates that it is a list of numbers but adds no clarity on the schema's ambiguous anyOf (raw array vs a string), which is exactly where extra prose would help.
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 and resource ('Calculates the arithmetic mean ... of a list of numbers') and even gives the algorithm, which implicitly separates it from siblings like calculate_median or calculate_standard_deviation. It stops short of naming those siblings explicitly, so differentiation relies on the reader inferring it from the term 'arithmetic mean'.
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?
No explicit when-to-use or when-not-to-use guidance and no named alternatives among the many math siblings (calculate_median, calculate_standard_deviation, calculate). Usage is only implied by the precise definition of what it computes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the area of geometric shapes including circle (πr²), triangle (½×base×height), rectangle (length×width), and square (side²). Returns area in square units. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| shape | No | string, required, shape type (circle/triangle/rectangle/square), no unit, no default | |
| measurements | No | object, required, shape-specific measurements (radius/base/height/length/width/side), appropriate units, no default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral detail beyond the annotations by stating the return unit ('square units') and a one-credit cost, though it does not mention precision, rounding, or error behavior.
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 and front-loaded: it names the operation, lists the formulas, states the return unit, and ends with the cost. Every sentence and clause adds useful information with no 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?
For a simple read-only calculator with full schema coverage and no output schema, the description covers supported cases, formulas, output units, and cost. It leaves only minor gaps around numeric precision, invalid input handling, and measurement formatting.
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 coverage is 100%, so the baseline is 3, but the description adds real meaning by mapping each shape to the measurements it expects through the listed formulas. This helps an agent understand what values belong in the generic 'measurements' parameter.
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 uses a specific verb and resource ('Calculates the area') and enumerates the supported shapes with formulas. It is clear what the tool does, but it does not distinguish itself from sibling geometry tools such as polygon_area_shoelace.
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 supported shape list implies the applicable scope, but there is no explicit when-to-use guidance, no exclusions, and no comparison with alternative area or geometry tools. The agent can infer usage from the formulas but must do the routing itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the smaller angle in degrees between the hour and minute hands of an analog clock given the time. Returns angle between 0 and 180 degrees. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| hour | No | integer, required, hour value (0-23 or 1-12) | |
| minute | No | integer, required, minute value (0-59) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely non-structured context: the output range (0–180 degrees, i.e. the smaller angle) and a cost of 1 credit, which is exactly the kind of quota/cost disclosure annotations cannot express.
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?
Three short sentences, each earning its place: what it computes, the return range, and the cost. The core purpose is front-loaded and nothing is padded.
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 pure function with fully described schema and no output schema, the description covers purpose, return range, and cost — enough to call it correctly. Only minor details, such as rounding or handling of identical-hour/12-hour notation, are left unstated but are effectively immaterial.
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%, with both hour (0-23 or 1-12) and minute (0-59) documented inline. The description adds no additional meaning about parameter encoding — notably it does not clarify that the parameters are typed as strings in the schema — so the baseline of 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?
The description names a specific verb and resource ('Calculates the smaller angle ... between the hour and minute hands of an analog clock') and pins down the exact quantity returned. Unlike the many vaguely named calculate_* siblings, an agent can tell precisely what this computes without opening the schema.
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 by the narrow, self-contained nature of the operation — there is no real alternative tool for clock-hand angles among the siblings. However, the description never states when to prefer it, or how to handle inputs like 12-hour vs 24-hour hours, leaving guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the great-circle distance between two geographic points using the Haversine formula. Returns distance in kilometers, miles, or nautical miles. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| lat1 | No | number, required, latitude of first point, decimal degrees, no default | |
| lat2 | No | number, required, latitude of second point, decimal degrees, no default | |
| lon1 | No | number, required, longitude of first point, decimal degrees, no default | |
| lon2 | No | number, required, longitude of second point, decimal degrees, no default | |
| unit | No | string, optional, unit of measurement (km/miles/nautical), no unit, default km |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral facts beyond those annotations: the underlying formula (fixed, deterministic result) and a per-call cost of 1 credit, which affects agent planning. It stops short of stating valid coordinate ranges or error behavior, which keeps it below a 5.
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 short sentences: the purpose and algorithm come first, the return format and cost second. No filler and nothing requiring the reader to scan ahead.
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-computation tool with full schema coverage, no output schema needed, and annotations covering safety, the definition tells the agent essentially everything required to call it. The only gap is that valid latitude/longitude bounds and out-of-range behavior are unstated, which is a minor omission rather than a blocking one.
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%, with every parameter documented including units ('decimal degrees') and the default of km for unit. The description only echoes the unit options already in the schema and adds no semantics about accepted string-vs-number coordinate formats or hemisphere sign conventions, so 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 precise verb and resource ('Calculates the great-circle distance between two geographic points'), names the algorithm (Haversine), and specifies the returned units. This clearly separates it from numeric siblings such as euclidean_distance without needing the schema opened.
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 by the domain: coordinates in degrees means geographic distance, which is enough for an agent to pick it over euclidean_distance. However, there is no explicit when-to-use statement, no mention of the alternative tool, and no note about precision limits or spherical-vs-ellipsoidal assumptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the median (middle value) of a list of numbers. For even-length lists, returns the average of the two middle values. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | No | array of numbers, required, list of numeric values to find the median of |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description still adds genuine behavioral value by specifying the even-length rule (averaging the two middle values) and the credit cost, though it omits what happens with an empty or non-numeric list.
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 tight sentences with the core behavior front-loaded, followed by the cost tag. Nothing is redundant or padded; the edge-case clause is worth its space.
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 single-parameter arithmetic tool with full annotation coverage and no output schema, the definition says enough to call it correctly, including the return semantics for even-length input. Only minor gaps remain around invalid input and the accepted string form of the parameter.
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 the schema already documents the single 'numbers' parameter, making 3 the baseline. The description reinforces that it expects a list of numeric values but does not clarify the schema's string alternative (anyOf array-of-strings or plain string), leaving that parsing detail undocumented.
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?
Names a specific verb and resource ('Calculates the median') and even pins down the edge case semantics ('middle value', average of two middle values for even-length lists). It does not explicitly distinguish itself from the many sibling statistics tools such as 'average' or 'calculate_standard_deviation', so it stops short of a 5.
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?
No guidance on when to choose this over the sibling 'average' or 'calculate_standard_deviation' tools, and no prerequisites or exclusions. The only indirect signal is the '(cost: 1 credit)' note, which hints at a budget consideration but says nothing about when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the population standard deviation of a list of numbers using the standard formula: sqrt(Σ(x - μ)² / N). (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | No | array, required, list of numeric values, no unit, no default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new operational context: the per-call cost of 1 credit and the exact deterministic formula being applied. It does not mention error behavior for empty or non-numeric input, which is the only notable gap.
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?
One front-loaded sentence states the verb, the resource, the statistical variant, the formula, and the cost, with no filler. Nothing could be removed without losing information an agent needs.
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 one-parameter, no-output-schema tool with rich annotations, the description covers purpose, computation method, and cost. The only shortfall is that it never indicates the return value is a single number, which matters slightly because there is no output schema to fall back on.
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 the schema already defines the single 'numbers' parameter, and baseline 3 applies. The description adds no clarification of the ambiguous anyOf form, which permits either an array of strings or a single string — an agent must guess whether a delimited string like "1,2,3" is acceptable.
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 names a specific operation ('Calculates the population standard deviation of a list of numbers') and even supplies the exact formula, which disambiguates it from siblings like calculate_median, average, or variance-style tools. An agent can identify the resource, the input shape, and the statistical variant without opening the schema.
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 only implied: the word 'population' signals that this is not the sample standard deviation, which is a real decision point for an agent. However, no alternatives (e.g. calculate_median, average) are named, and there is no when-to-use or when-not-to-use guidance despite a very crowded calculation-tool sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs a Chi-Square test for independence on a 2x2 contingency table. Returns the chi-square statistic, p-value, and whether to reject the null hypothesis at the given significance level. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| contingency_table | No | 2D array, required, 2x2 table of observed frequencies [[a, b], [c, d]] | |
| significance_level | No | number, required, significance level for the test (e.g., 0.05 for 5%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, non-destructive), so the description focuses on useful extras: the 2x2 size restriction, the exact returned values including the reject/fail-to-reject decision, and a cost of 1 credit. It does not state behavior for invalid or degenerate tables, which keeps it off a 5.
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 what the tool computes, followed by what it returns and its cost. No redundant or filler wording.
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 low-complexity, low-parameter tool with no output schema, the description supplies both the computation and the return values, which is most of what an agent needs. It omits input-validation behavior for malformed or zero-cell tables, a minor remaining gap.
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%, with both parameters documented including the [[a, b], [c, d]] layout and a 0.05 significance example, so the baseline of 3 applies. The description only restates the 2x2 table shape and 'given significance level' without adding format or edge-case semantics beyond the schema.
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 statistical verb and resource ('Chi-Square test for independence on a 2x2 contingency table') and immediately names the outputs. No sibling tool performs a chi-square test, so the name-plus-description pair is unambiguous against the surrounding calculator tools.
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 context is implied by the '2x2 contingency table' restriction and the 'reject the null hypothesis' framing, so a knowledgeable agent knows when it applies. However, there is no explicit when-to-use/when-not guidance (e.g., minimum expected cell counts, what to do for larger tables) or pointer to any alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the cosine similarity between two vectors, returning a value between -1 and 1 where 1 indicates identical direction. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| vector_a | No | array of numbers, required, the first vector | |
| vector_b | No | array of numbers, required, the second vector (must be same length as vector_a) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds two useful behavioral facts beyond that: the output range (-1 to 1 with directional meaning) and the cost of 1 credit. It says nothing about failure behavior, e.g. what happens when vector lengths differ or when inputs are given as strings rather than number arrays.
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 stating the operation, its output range and interpretation, with the cost in a short parenthetical. No filler and no redundancy with the title or annotations.
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, side-effect-free computation with no output schema, the definition covers purpose, return range and cost, which is nearly everything an agent needs. The remaining gap is input-format and error handling, particularly the anyOf schema that technically permits string vectors despite the schema text saying 'array of numbers'.
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 and the equal-length constraint are already documented in the schema. The description adds no parameter-level meaning beyond that, which is the expected baseline of 3 when the schema does the work.
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 names a specific verb ('Calculates') and resource ('cosine similarity between two vectors') and even states the output range and its interpretation, so the operation is unambiguous. It does not name a sibling such as euclidean_distance to distinguish itself, which is the only thing keeping it from a 5.
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 on when to choose this tool over alternatives in the large sibling set (euclidean_distance, average, linear_regression_prediction, etc.), nor any stated preconditions such as equal vector lengths or numeric input format. The agent must infer all selection logic from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a histogram by counting the frequency of data points falling into specified bins or ranges. Returns the frequency count for each bin. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| bins | No | integer or array, required, number of bins or array of bin edges | |
| data | No | array of numbers, required, data points to create histogram from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description stays consistent while adding two pieces of information the annotations do not carry: the cost ('1 credit') and the shape of the result ('frequency count for each bin'). It does not discuss error handling for non-numeric or out-of-range data, but for a read-only computation that is a minor gap.
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 tight sentences that front-load the operation and then the return value, with the cost note appended in parentheses. Nothing is wasted, though the second sentence slightly repeats the counting idea from the first.
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?
With no output schema, the description usefully states what is returned, and the schema fully covers the two inputs; cost is also disclosed. Missing only edge-case behavior (empty data, non-numeric input, how bin count vs. bin edges interact), which keeps it from a 5.
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 coverage is 100%, so both parameters (bins, data) are already documented, including the integer-or-edge-array duality for bins. The description only restates 'specified bins or ranges' without adding syntax, defaults, or ordering rules, so the 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?
The description uses a specific verb+resource pair ('Creates a histogram') and elaborates the mechanism ('counting the frequency of data points falling into specified bins or ranges'), which is enough for an agent to distinguish it from generic calculators like average or calculate_median. It stops short of explicitly naming any sibling tool, but no sibling competes for the same operation.
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 by the description itself: use it when you need frequency counts per bin rather than summary statistics. There is no explicit when-to-use/when-not-to-use guidance or pointer to an alternative for agents deciding between this and the summary-statistics tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the probability of rolling a specific sum with a given number of dice, each with a specified number of faces. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| num_dice | No | integer, required, number of dice to roll | |
| num_faces | No | integer, required, number of faces on each die | |
| target_sum | No | integer, required, the desired sum to calculate probability for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral information by disclosing a metered cost ('cost: 1 credit'), which annotations never express. It says nothing about output shape or edge cases (e.g. impossible sums), so it is not rich beyond that.
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 short sentences with the core purpose front-loaded and the cost note clearly parenthesized at the end. No padding or redundancy, though the single-sentence purpose could have been tightened slightly by folding the faces qualifier.
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 simple, stateless pure-computation tool with no output schema and full schema coverage, so the description needn't explain return values or ordering. The only real omission is differentiation from probability_consecutive_rolls and any note on invalid inputs (target sum outside achievable range).
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%, and each parameter is documented as 'integer, required' with its role, so the schema carries the load. The description restates the semantics of num_dice, num_faces and target_sum in prose but adds no constraint, range, or validation detail beyond the schema — the 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?
The description names a specific verb ('Calculates the probability') and the exact resource ('rolling a specific sum with a given number of dice, each with a specified number of faces'), which maps cleanly onto the three parameters. It does not, however, distinguish itself from the sibling probability_consecutive_rolls, so an agent must infer the boundary between single-sum and consecutive-roll probability.
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 phrasing implicitly signals the use case (you want the probability of one target sum), but there is no explicit when-to-use, when-not-to-use, or pointer to probability_consecutive_rolls for the related scenario. Selection between the two probability siblings is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the Euclidean distance between two points in a 2D plane using the formula: sqrt((x2-x1)² + (y2-y1)²). (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| point_a | No | array of two numbers, required, coordinates of first point [x, y] | |
| point_b | No | array of two numbers, required, coordinates of second point [x, y] |
Does 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 needs no restating. The description does add something the annotations lack: a per-call quota ('cost: 1 credit') and the exact deterministic formula. It says nothing about return type or behavior when inputs are non-numeric or the wrong length, which is the main remaining gap.
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 gives the operation, the domain constraint, and the formula, with the cost note appended compactly. The formula is arguably redundant for an agent but is short and reinforces determinism, so nothing meaningfully wasteful remains.
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 pure-computation tool with full schema coverage and complete safety annotations, the description supplies everything needed to call it; the formula implies a numeric scalar result. Minor omissions are the lack of sibling differentiation and of input-error behavior.
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 as '[x, y]' coordinate arrays. The description only restates 'two points in a 2D plane' and adds no format detail such as whether a CSV-style string is accepted or what happens on dimension mismatch, so it sits at the baseline.
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 verb and resource ('Computes the Euclidean distance between two points in a 2D plane') and even gives the exact formula, so the operation is unambiguous. It does not, however, distinguish itself from the sibling 'calculate_distance' or from 'cosine_similarity', leaving the agent to infer which distance tool to pick.
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 explicit when-to-use guidance and no named alternative. The only implicit scoping is 'in a 2D plane', which hints that 3D or higher-dimensional inputs are out of scope, but the agent must infer that and must guess how this differs from the sibling calculate_distance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the factorial of a non-negative integer n, which is the product of all positive integers less than or equal to n. Returns n! = n × (n-1) × ... × 1. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| number | No | integer, required, non-negative integer to calculate factorial of |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds a useful cost signal ('cost: 1 credit') that annotations do not carry. However it omits meaningful behavior for this operation — no stated upper bound on n, no note that very large n produces enormous or unbounded output, and no mention of how a string-typed 'number' parameter is parsed. No contradiction with annotations.
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?
Front-loaded with the verb and resource in the first clause, with the formula and cost trailing. The restatement of the definition as a product and then as a formula is mildly redundant, but overall it is short and every element is on-topic.
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 one-parameter pure computation with no output schema and strong read-only annotations, the description covers what the tool does and what it costs. The remaining gap — practical bounds on n and overflow behavior — is minor given the tool's simplicity, though it would be the one addition that materially improves it.
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 coverage is 100% and the single parameter's description already says 'integer, required, non-negative integer to calculate factorial of'. The description restates the same non-negative constraint but adds no format detail (e.g., whether the string accepts leading signs, whitespace, or a max value), so 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 and resource — "Calculates the factorial of a non-negative integer n" — and even restates the result formula, so the operation is unambiguous. It does not differentiate itself from mathematical siblings such as fibonacci, permutation_count, or greatest_common_divisor, but the operation itself is not confusable.
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 only implied: an agent can infer you call this when you need n!. There is no explicit 'use this instead of X' routing (e.g., permutation_count for arrangements), no guidance on input constraints beyond 'non-negative', and no mention of a maximum n where results overflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates the first n numbers in the Fibonacci sequence, where each number is the sum of the two preceding ones, starting with 0 and 1. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | integer, required, number of Fibonacci numbers to generate (must be positive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: the credit cost of one per call and the exact sequence convention. It stops short of saying what the return shape is (list vs string), which is the main remaining gap.
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 with the core behavior first and the cost note parenthesized at the end. Nothing is redundant or padded.
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 one-parameter, side-effect-free computation tool with full schema coverage and no output schema, the description gives everything needed to invoke it correctly. The only soft spot is not describing the returned value's shape, which is minor for such a predictable output.
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% and the parameter documents 'number of Fibonacci numbers to generate (must be positive)', so the schema carries the semantics. The description restates 'first n numbers' but adds no format, upper-bound, or type clarification, leaving the schema's string-typed 'n' described as an integer unaddressed. 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?
The description names a specific verb ('Generates') and resource ('the first n numbers in the Fibonacci sequence') and pins down the exact sequence convention (each number is the sum of the two preceding, starting 0 and 1). An agent can distinguish it from neighbours like factorial or is_prime without opening the schema.
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 by the definition rather than stated: an agent can infer it should call this when it needs Fibonacci numbers. There is no explicit when-to-use, no when-not-to-use, and no mention of the sibling math tools (factorial, least_common_multiple) it could be confused with.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the greatest common divisor (GCD) of two non-negative integers using the Euclidean algorithm. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| a | No | integer, required, the first non-negative integer | |
| b | No | integer, required, the second non-negative integer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description still adds value by disclosing the algorithm (Euclidean) and the cost of 1 credit, though it never says what the call returns or how degenerate inputs like 0,0 are handled.
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 compact sentences, front-loaded with the verb and resource, with the cost parenthetical appended so it does not obstruct the definition. No redundant or filler wording.
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, side-effect-free computation with full schema coverage and rich annotations, the description supplies everything needed to select and invoke it correctly. Only the return value (a single integer, and the gcd(0,0) convention) is left unspecified, which is a minor gap.
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 (a, b) are already documented as required non-negative integers. The description restates the domain (non-negative) but adds no syntax, range, or format detail beyond the schema — the baseline 3 is appropriate.
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 (computes) and resource (greatest common divisor of two non-negative integers), plus the algorithm used. The scope is unambiguous and clearly distinct from siblings such as least_common_multiple or is_prime.
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 only implied by the mathematical definition — an agent can infer this is the tool for GCD, but there is no explicit when-to-use rule, no naming of the nearest alternative (least_common_multiple), and no note on prerequisites or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks if a number is a power of two (2^n for some non-negative integer n). (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| num | No | integer, required, the number to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered elsewhere. The description adds a genuinely useful non-annotation detail — the "cost: 1 credit" charge — plus the definitional constraint of non-negative n, but it does not say what the response looks like or how 0/1 are treated.
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?
One compact sentence with the core purpose front-loaded, followed by the precise definition and the cost note. No filler, no redundancy.
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 one-parameter boolean predicate with full schema coverage and annotations covering safety and idempotency, the description supplies what an agent needs plus the credit cost. The only remaining gap is the unspecified return value/edge-case behavior, which is minor for a tool this simple.
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% and the single parameter is documented as "integer, required, the number to check". The description adds no additional parameter meaning (e.g. accepted range, handling of negatives or string-formatted integers), so the baseline of 3 for a fully-covered schema 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?
The description names a specific verb+resource ("Checks if a number is a power of two") and pins the exact mathematical definition (2^n for some non-negative integer n), which inherently separates it from siblings like is_prime, is_perfect_square, and is_power. It never explicitly names those siblings, so the differentiation is left implicit.
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 when-to-use guidance and no reference to the closely related siblings (is_power, is_perfect_square) that an agent would have to choose between. Edge cases such as 0, 1, or negative input are not addressed, so selection and invocation are left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks if a positive integer is a prime number (only divisible by 1 and itself). Returns false for numbers less than 2. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| num | No | integer, required, the number to test for primality, no units, no default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent, non-destructive operation. Beyond that, the description adds useful behavior: it returns false for numbers less than 2 and costs 1 credit.
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 definition is front-loaded in one clear sentence, with the edge case and cost placed compactly in parentheses. There is no unnecessary wording.
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 one-parameter boolean predicate with no output schema, this is largely complete: purpose, definition, edge case, and cost are covered. It could be slightly more explicit that the normal return is true/false, but that is strongly implied.
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 coverage is 100%, so the single parameter is already documented. The description adds semantic domain information by specifying that the input is a positive integer and clarifying the less-than-2 edge case.
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 gives a specific verb and resource: checks whether a positive integer is prime, and even defines primality. It is unambiguous against math siblings such as is_perfect_square or is_power because the operation is exactly primality testing.
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 context is clear: use this to test primality. It also states the boundary behavior for numbers less than 2, which helps an agent decide when the tool applies, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the least common multiple (LCM) of two positive integers using the relationship LCM(a,b) = (a × b) / GCD(a,b). (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| a | No | integer, required, the first positive integer | |
| b | No | integer, required, the second positive integer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered by structured data. The description adds real value beyond that: it discloses a per-call cost ('1 credit'), states the underlying computation method (deterministic GCD-based formula), and constrains inputs to positive integers. It doesn't say what happens on invalid input, but with annotations in place this is a solid addition.
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 with no wasted phrasing, and the cost note is a useful parenthetical. The mathematical formula is not strictly necessary for invoking the tool, which keeps it just short of ideal conciseness.
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 trivial two-argument pure-math tool with full schema coverage and annotations covering safety and idempotency, this is complete. The only conceivable gap is the return-value type, which is inferable from 'least common multiple' and unproblematic given the absence of an output schema.
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 'a' and 'b' are already documented as required positive integers. The description only restates 'two positive integers' and names them in the formula, adding no new meaning such as range limits or behavior for large values. Baseline 3 applies when the schema carries the semantics.
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 names a specific verb ('Computes') and resource ('least common multiple (LCM)') with scope ('of two positive integers'). It is trivially distinguishable from the sibling greatest_common_divisor, and the stated GCD-based identity confirms exactly what is being computed.
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 explicit when-to-use or when-not-to-use guidance and no mention of the related greatest_common_divisor sibling. The 'two positive integers' phrasing implies an input constraint, but an agent gets no routing advice or edge-case handling guidance from the text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predicts the y-value for a given x-value using simple linear regression (least squares method) fitted to the provided data points. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| target_x | No | number, required, the x-value for which to predict y | |
| x_values | No | array of numbers, required, the x-coordinates of data points | |
| y_values | No | array of numbers, required, the y-coordinates of data points (same length as x_values) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful context in the form of the least-squares method and a one-credit cost, but it does not describe error behavior, data-length requirements, or the exact return shape.
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 front-loaded sentence that states the operation and method, followed by a compact cost note. There is no redundant or wasted wording.
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 stateless calculation tool with full input-schema coverage and complete safety annotations, the definition is nearly complete. The missing detail is mainly what the prediction returns and any minimum-data or error constraints, but the core behavior is clear.
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 target_x, x_values, and y_values are already well documented in the schema. The description refers to x-values, y-values, and fitted data points but does not add syntax or validation meaning beyond what the schema provides.
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 names a specific verb and output: it predicts a y-value for a given x-value. It also identifies the exact method, simple linear regression via least squares, fitted to the provided data points, which makes it distinguishable from generic calculator or average tools.
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 by the description: use this when you need a simple linear regression prediction from supplied x/y data points. However, it gives no explicit when-to-use conditions, prerequisites such as minimum data-point requirements, or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the number of permutations P(n,k) = n!/(n-k)! representing ordered arrangements of k elements selected from n elements. Returns the count as an integer. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | integer, required, number of elements to select (must be 0 ≤ k ≤ n) | |
| n | No | integer, required, total number of elements (must be non-negative) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the description only needs to add what they don't say. It does add two useful facts — the return type (integer) and a cost of 1 credit — but says nothing about error behavior when k exceeds n, which is the only realistic failure mode.
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?
Three short sentences, front-loaded with the formula so the agent knows what is being computed immediately, then the return type, then the cost note. No padding; the definition sentence is slightly dense but each clause carries meaning.
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 pure-computation tool with no output schema, the definition covers what is computed, the formula, the return type, and the cost. The only gap is what happens on invalid input (k > n), which the schema's constraint text partially covers.
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%, and the schema already states the constraints (0 ≤ k ≤ n, n non-negative). The description's gloss of k as 'elements selected' and n as 'total elements' mostly restates the schema, adding only the P(n,k) framing.
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 ('Calculates') and resource ('number of permutations'), and pins it down with the exact formula P(n,k) = n!/(n-k)! plus a plain-English gloss ('ordered arrangements'). That is enough to distinguish it from the nearest sibling, factorial, without opening either schema, though it never names that alternative explicitly.
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 only implied: the phrase 'ordered arrangements' signals this is the ordered counterpart to an unordered combination, but no when-to-use, when-not-to-use, or alternative tool is named. An agent must infer the routing decision itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the area of a polygon given its vertices using the shoelace formula (also known as the surveyor's formula). (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| vertices | No | array of [x, y] coordinate pairs, required, the vertices of the polygon in order |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds one genuinely new fact — a cost of 1 credit — but says nothing about behavior on degenerate input (collinear or self-intersecting polygons) or the sign of the result for reversed vertex order.
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 short clauses, front-loaded with the operation and algorithm, with the cost note trailing. The parenthetical alias 'surveyor's formula' is marginally redundant but aids recognition; nothing else is wasted.
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 single-parameter, annotation-rich tool this is close to adequate. However there is no output schema, so the description should say what comes back (a numeric area in squared units) and whether reversed vertex order yields a negative value — the one thing an agent cannot get from the structured fields.
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%, and the schema already documents 'vertices' as ordered [x, y] coordinate pairs. The description adds only the implied consequence that vertex order feeds a shoelace sum; it gives no format examples, no note on accepting a flat string vs array beyond what the anyOf already shows. 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 and resource ('Calculates the area of a polygon') and names the exact algorithm (shoelace/surveyor's formula), which is far more specific than the sibling 'calculate_area'. It stops short of explicitly contrasting itself with that sibling, so an agent must infer the difference.
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 on when to prefer this over 'calculate_area' or other geometry tools, and no prerequisites such as a minimum of three vertices, whether the ring should be closed, or whether clockwise vs counter-clockwise ordering matters. The agent is left to infer all of that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the probability of rolling a specific value consecutively for a given number of rolls on a die with specified sides using the formula (1/num_sides)^num_rolls. Returns probability as a decimal between 0 and 1. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| num_rolls | No | integer, required, number of consecutive rolls (must be positive) | |
| num_sides | No | integer, required, number of sides on the die (must be positive) | |
| target_value | No | integer, required, the target value to roll (must be between 1 and num_sides) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description usefully adds the credit cost and the return range ('decimal between 0 and 1'), which annotations do not convey. It says nothing about edge cases such as invalid inputs or rounding/precision of the returned decimal.
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 compact sentences: the operation and formula first, then the return value and cost. Nothing is padded, though the cost parenthetical could arguably be a separate structured field rather than description prose.
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 three-parameter math tool with no output schema, the description covers the computation and the result format adequately. However, the unexplained role of the required target_value parameter (absent from the given formula) is a real completeness gap an agent could trip over.
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 (including the 1..num_sides constraint on target_value) are already documented in the schema, making 3 the baseline. The description does add that num_sides and num_rolls feed the formula, but it creates ambiguity by never explaining target_value, which the stated formula does not actually use.
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 gives a specific verb ('Calculates') plus a precise resource (probability of consecutive identical rolls on an N-sided die) and even states the exact formula. It does not, however, differentiate itself from the sibling dice_roll_probability, so an agent must infer which of the two to pick.
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 when-to-use guidance, no exclusions, and no pointer to the closely related sibling dice_roll_probability. The only extra context is a cost note, which is billing information rather than selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the real and complex roots of a quadratic equation ax² + bx + c = 0 using the quadratic formula. Returns both roots or indicates if no real solutions exist. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| a | No | number, required, coefficient of x² term (must be non-zero) | |
| b | No | number, required, coefficient of x term | |
| c | No | number, required, constant term |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered and the description does not repeat it. The description does add useful behavior (cost of 1 credit, return of roots) but is internally ambiguous: it promises 'real and complex roots' yet also says it 'indicates if no real solutions exist', leaving unclear whether complex roots are actually returned or replaced by a no-solution message.
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 tight sentences plus a cost tag; the operation and formula are front-loaded and nothing is padded. The only efficiency cost is the mild redundancy between the stated purpose and the return sentence, which repeats the 'roots' idea with a conflicting caveat.
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 three-coefficient pure function whose annotations already cover safety, the description gives the operation, the domain, and a rough sense of the return. The remaining gap—no output schema and no statement of how complex roots are shaped (object, string, or flag)—is minor but real for an agent parsing the result.
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% and each coefficient is documented there, including the non-zero constraint on 'a', so the schema does the heavy lifting. The description adds only the conventional ax² + bx + c framing, which is helpful context but no meaning beyond the schema, and says nothing about why the schema permits string inputs.
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 and resource plus the exact computation domain: 'Computes the real and complex roots of a quadratic equation ax² + bx + c = 0 using the quadratic formula.' This clearly separates it from generic siblings like calculate, average, or is_perfect_square without opening any schema.
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 strongly implied by the mathematical scope (only quadratics, only root-finding), but there is no explicit when-to-use or when-not guidance and no named alternative among the many math siblings. An agent can infer applicability from the formula stated, which is the minimum-viable bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
averagecalculate_areacalculate_clock_anglecalculate_distancecalculate_mediancalculate_standard_deviationchi_square_independence_testcosine_similaritycreate_histogramdice_roll_probabilityeuclidean_distancefactorialfibonaccigreatest_common_divisoris_power_of_twois_primeleast_common_multiplelinear_regression_predictionpermutation_countpolygon_area_shoelaceprobability_consecutive_rollssolve_quadraticExact statistics & probability: distributions, hypothesis tests, CIs, Bayesian updates, regression.
Safe maths and statistics, and UK working-day arithmetic using official bank holidays
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Exact arithmetic, algebra, calculus, physics, chemistry and finance with a checkable formula.
Add one secure layer between your agents and this server.
