calculator

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap in mathematical functions (e.g., trigonometric and hyperbolic functions have separate tools for each, which could cause confusion if not carefully described). However, the descriptions are clear enough to differentiate them.
Naming Consistency4/5
The naming is mostly consistent with a verb_noun or noun pattern, but there are minor deviations like 'bellNumber' (camelCase) and 'area_conversion' (snake_case). Overall, it remains readable and predictable.
Tool Count2/5
With 101 tools, the count is excessive for a calculator server, making it overwhelming and likely to cause agent confusion. A more focused set of core functions would be more appropriate.
Completeness5/5
The tool set comprehensively covers a wide range of mathematical, geometric, financial, and conversion operations, with no obvious gaps. It includes basic arithmetic, advanced functions, and domain-specific calculations.
Average 2.8/5 across 101 of 101 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('计算普通年金的未来值') without disclosing any behavioral traits such as whether it's a read-only calculation, error handling, or output format. This is inadequate for a tool with parameters and no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('计算普通年金的未来值'), which is appropriately sized and front-loaded with the core purpose. There is no wasted text, making it concise, though it could benefit from more detail given the lack of other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (financial calculation with 3 parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on parameter semantics, usage context, and expected output, making it inadequate for effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description does not add any meaning beyond the schema—it does not explain what 'payment', 'periods', or 'interest_rate' represent, their units, or how they interact. For a tool with 3 parameters and low coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算普通年金的未来值' (calculates the future value of an ordinary annuity) states the specific verb '计算' (calculate) and resource '普通年金的未来值' (future value of an ordinary annuity), which is clear. However, it does not distinguish from sibling tools like 'present_value_annuity' or 'compound_interest', making it vague in differentiation. It avoids tautology by not restating the name/title directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention when to prefer this over 'present_value_annuity' or other financial tools in the sibling list, nor does it specify any context or exclusions for usage. This lack of guidance leaves the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the conversion function without detailing traits like supported units, precision, error handling, or output format. This is inadequate for a tool with parameters and no output schema, leaving critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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 function without unnecessary words. It is appropriately sized for a simple conversion tool, though it could be more informative. The structure is front-loaded with the core purpose, but lacks elaboration that might be needed for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It does not explain the return values, error conditions, or behavioral details necessary for effective use. While the purpose is stated, the lack of annotations and output schema means the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'different area units' which hints at 'from_unit' and 'to_unit', but does not specify allowed units or formats. It implies 'value' as the numeric input but adds no semantic context beyond the schema. This partially addresses parameters but falls short of fully compensating for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as converting between area units, which is clear but vague. It specifies 'different area units' without naming examples or distinguishing from sibling tools like length_conversion or volume_conversion, though the tool name itself provides some differentiation. It avoids tautology by not merely restating the name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention sibling tools like length_conversion or volume_conversion, nor does it specify prerequisites or exclusions. Usage is implied by the general purpose but lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the conversion action without disclosing behavioral traits like error handling, supported unit formats, precision, or return format. This leaves critical operational details unspecified for a tool with three parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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 function. It's front-loaded with the core purpose, though it could be more structured by including key details without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and three parameters, the description is incomplete. It doesn't explain what the tool returns, how errors are handled, or provide enough detail to use the tool correctly beyond the basic concept of length conversion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions 'length units' which gives some context for from_unit and to_unit, but doesn't explain what units are valid, their syntax, or the meaning of value beyond being a number. This is inadequate for three undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '在不同长度单位之间进行转换' (converts between different length units) states the general purpose but lacks specificity about what length units are supported or how the conversion works. It distinguishes from siblings like area_conversion or volume_conversion by focusing on length, but doesn't clarify scope beyond that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like speed_conversion or weight_conversion. The description implies it's for length units only, but doesn't mention prerequisites, limitations, or comparison to other conversion tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but adds no behavioral details. It doesn't disclose whether this is a read-only operation, what the output format is, error handling, or performance considerations. For a mathematical tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. It's front-loaded with no wasted words, making it highly concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter meanings, or output details. For a mathematical tool with 2 parameters, this leaves significant gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 but adds no parameter information. It doesn't explain what 'real' and 'imag' represent, their units, or constraints. With 2 undocumented parameters, the description fails to provide meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算复数的共轭' (calculates the complex conjugate) states the verb and resource but is vague about scope and differentiation. It doesn't specify whether it handles single numbers or arrays, or how it differs from sibling tools like complex_add or complex_magnitude. The purpose is clear but lacks specificity and sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, such as when to choose complex_conjugate over other complex operations like complex_polar or complex_argument. Usage is implied from the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 but only states the mathematical operation. It doesn't describe error handling (e.g., for invalid inputs), performance characteristics, domain/range limitations, or output format. For a mathematical function tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one phrase ('计算双曲余弦值'), which is front-loaded and contains zero wasted words. For a simple mathematical function, this brevity is appropriate and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical function with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. While the purpose is clear, it lacks parameter details, behavioral context, and usage guidance that would help an agent invoke it correctly in various mathematical contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about the single parameter 'value'. It doesn't explain what 'value' represents (e.g., input number in radians or degrees), valid ranges, or special cases. With one undocumented parameter, the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算双曲余弦值' (calculates hyperbolic cosine value) clearly states the verb ('计算' - calculate) and resource ('双曲余弦值' - hyperbolic cosine). It distinguishes from siblings like 'cos' (cosine) and 'sinh' (hyperbolic sine) by specifying the hyperbolic cosine function, though it doesn't explicitly differentiate from 'acosh' (inverse hyperbolic cosine).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 hyperbolic cosine calculations are appropriate compared to regular cosine ('cos') or other hyperbolic functions ('sinh', 'tanh'), nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic function without any details on error handling (e.g., for incompatible dimensions), performance characteristics, output format, or computational limits. This is inadequate for a tool that performs mathematical operations with potential constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 without any fluff. It's front-loaded and wastes no words, making it highly concise and well-structured for its minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of matrix multiplication (involving dimension compatibility and mathematical operations), lack of annotations, 0% schema coverage, and no output schema, the description is severely incomplete. It fails to address key contextual aspects like input formats, error conditions, or result details, making it inadequate for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, with two parameters (matrix_a and matrix_b) having no schema descriptions. The description adds no semantic information about parameters—it doesn't specify that matrices should be 2D arrays, mention dimension requirements, or provide examples. With low coverage and no compensation in the description, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算两个矩阵的乘积' (calculates the product of two matrices) clearly states the verb (calculate) and resource (matrix product). It distinguishes from siblings like matrix_add, matrix_subtract, matrix_inverse, etc., by specifying multiplication rather than other matrix operations. However, it doesn't explicitly mention that it's for numerical matrices or contrast with scalar multiplication (handled by 'multiply'), so it's not fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites (e.g., matrix dimensions must be compatible), exclusions (e.g., not for scalar multiplication), or refer to sibling tools like matrix_add for other operations. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the calculation without disclosing behavioral traits like input validation (e.g., matrix dimensions must match), error handling, performance considerations, or output format. This is inadequate for a mutation-like operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese with no wasted words. It's appropriately sized for a simple mathematical operation and front-loaded with the core purpose, though it lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (matrix operation with potential dimension constraints), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't address key aspects like input validation, error cases, or return values, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description doesn't add any parameter semantics beyond the names 'matrix_a' and 'matrix_b'. It doesn't explain what these parameters represent (e.g., 2D arrays), their expected formats, or constraints like size compatibility. With 2 undocumented parameters, the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算两个矩阵的差' (calculates the difference between two matrices) states the verb and resource clearly, but it's vague about what 'difference' means mathematically (element-wise subtraction) and doesn't distinguish from sibling tools like 'matrix_add' or 'subtract'. It provides basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'matrix_add' or general 'subtract'. The description implies usage for matrix operations but doesn't specify context, prerequisites, or exclusions, leaving the agent to infer based on tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does mathematically without any information about error handling, input validation, performance characteristics, or what happens with invalid matrices. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical operation tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address what happens with non-numeric inputs, rectangular vs square matrices, error conditions, or the format of the return value. The context demands more information than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and a single parameter 'matrix' that has no schema description, the description provides no additional information about parameter semantics. It doesn't explain what format the matrix should be in, what dimensions are supported, or any constraints on the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算矩阵的转置' (calculates the transpose of a matrix) clearly states the verb ('计算' - calculate) and resource ('矩阵的转置' - matrix transpose). It's specific about the mathematical operation, though it doesn't explicitly distinguish from siblings like matrix_add or matrix_multiply, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of prerequisites, when this operation is appropriate, or what distinguishes it from other matrix operations in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the calculation purpose without any behavioral context: no information about input validation (e.g., handling empty arrays, non-numeric values), error conditions, performance characteristics, or output format. This is inadequate for a tool with undocumented parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 with zero wasted words. It's appropriately front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a statistical calculation tool with no annotations, 0% schema coverage, no output schema, and 1 parameter, the description is completely inadequate. It lacks essential information about parameter requirements, behavioral expectations, error handling, and output format that would be needed for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), and the description provides no parameter information beyond the name 'numbers'. It doesn't explain what type of array elements are expected (numbers only?), whether the array must be sorted, or any constraints on array size or values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算数组的中位数' (calculates the median of an array) clearly states the verb ('计算' - calculate) and resource ('数组的中位数' - median of an array). It distinguishes from siblings like 'mean' or 'mode' by specifying the statistical measure. However, it doesn't explicitly differentiate from all mathematical/statistical siblings beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'mean', 'mode', or other statistical functions. The description only states what it does, not when it's appropriate or what distinguishes it contextually from similar tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool calculates NPV but doesn't describe what the calculation returns, whether it handles edge cases (like negative cash flows), what units the parameters should be in, or any limitations. For a financial calculation tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence in Chinese that translates to 'Calculate the net present value (NPV) of investment projects.' While it could be more informative, it's not verbose or repetitive. Every word serves a purpose, though more content would be beneficial.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial calculations, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what NPV calculation returns, how to interpret results, parameter requirements, or provide any context about the mathematical formula being applied. For a tool with 3 parameters performing financial analysis, this minimal description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so all 3 parameters are completely undocumented in the schema. The description provides no information about what 'initial_investment', 'cash_flows', or 'discount_rate' represent, their expected formats (e.g., currency units, time periods for cash flows, discount rate as decimal or percentage), or any constraints. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool calculates net present value (NPV) for investment projects, which is a specific purpose. However, it doesn't distinguish this from sibling tools like 'internal_rate_of_return' or 'present_value_annuity' which are related financial analysis tools. The description is clear about what it does but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are several related financial tools in the sibling list (internal_rate_of_return, present_value_annuity, future_value_annuity, bond_price, compound_interest) but the description offers no comparison or context for choosing NPV over these other financial analysis methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the calculation action without mentioning error handling (e.g., for negative numbers with even roots), performance, or output format. This is inadequate for a mathematical operation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function without unnecessary words. It's appropriately sized and front-loaded, with zero waste, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mathematical root calculation (which can involve edge cases like negative inputs), no annotations, no output schema, and 0% parameter coverage, the description is incomplete. It lacks details on behavior, parameters, and output, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, with two required parameters ('a' and 'n') undocumented in both the schema and description. The description implies parameters for the number and root degree but doesn't specify which is which or add any semantic details beyond the basic mathematical concept, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算数字的n次方根' (calculates the nth root of a number) states the tool's purpose with a specific verb ('计算') and resource ('数字的n次方根'), but it doesn't distinguish it from sibling tools like 'sqrt' (square root) or 'cbrt' (cube root). The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'sqrt' or 'cbrt', nor does it mention any prerequisites or context for usage. It only states what the tool does, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions calculating properties but doesn't disclose behavioral traits such as what specific properties are returned (e.g., area, perimeter, diagonal), the format of output, error handling for invalid inputs, or performance considerations. This leaves significant gaps for an AI agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence in Chinese, efficiently stating the purpose without unnecessary words. It's front-loaded with the main action. However, the vagueness of '等属性' slightly reduces clarity, but it's not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a calculation tool with 2 parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on what properties are calculated, output format, and parameter meanings, making it insufficient for an AI agent to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (length and width) with 0% description coverage, meaning no schema descriptions exist. The tool description does not add any parameter semantics—it doesn't explain what length and width represent, their units, valid ranges, or how they relate to the calculations. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool calculates rectangle properties like area and perimeter, which is a clear purpose. However, it's somewhat vague with '等属性' (and other properties) without specifying what those might be, and it doesn't differentiate from sibling geometry tools like circle_calculation or triangle_calculation beyond the shape type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. While the name implies rectangle-specific calculations, the description doesn't mention when it's appropriate compared to other geometry tools or general calculation tools like multiply or add. No explicit when/when-not statements are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does at a high level without revealing any behavioral traits: it doesn't mention what units are supported, whether conversion is bidirectional, precision considerations, error handling for invalid units, or what the output format looks like. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence ('在不同速度单位之间进行转换'). It's front-loaded with the core purpose and contains no unnecessary words or redundant information. Every word earns its place in conveying the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. For a conversion tool, users need to know what units are supported, the format of input/output, and any constraints. The current description provides none of this essential context, making it insufficient for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (value, from_unit, to_unit) have descriptions in the schema. The tool description provides no information about these parameters beyond what's implied by the tool name. It doesn't explain what units are acceptable, whether they should be abbreviations or full names, or provide examples of valid unit values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '在不同速度单位之间进行转换' clearly states the tool's purpose as converting between speed units. It specifies the verb '转换' (convert) and the resource '速度单位' (speed units), making the function unambiguous. However, it doesn't explicitly differentiate from sibling conversion tools like 'length_conversion' or 'temperature_conversion' beyond mentioning speed specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are multiple sibling conversion tools (area_conversion, length_conversion, temperature_conversion, time_conversion, volume_conversion, weight_conversion), but the description doesn't indicate when speed conversion is appropriate versus other unit conversions or mathematical operations. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the conversion function without any details on behavior such as precision, error handling (e.g., invalid units), return format, or whether it's a read-only operation. This leaves significant gaps for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't provide enough context for an agent to understand how to use the tool effectively, such as supported units, expected output, or error conditions. The simplicity of the tool might mitigate this slightly, but key details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters ('value', 'from_unit', 'to_unit') are documented in the schema. The description does not add any meaning beyond the schema—it doesn't explain what units are supported, the format of unit strings, or examples of valid inputs. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '在不同时间单位之间进行转换' (Convert between different time units) clearly states the tool's purpose with a specific verb ('转换' - convert) and resource ('时间单位' - time units). It distinguishes from siblings like 'length_conversion' or 'temperature_conversion' by specifying the domain of time. However, it doesn't explicitly mention the mathematical nature of the conversion, which might be inferred from sibling tools but isn't stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any prerequisites, context for use, or comparisons with other conversion tools (e.g., 'speed_conversion' might involve time units but isn't referenced). The agent must infer usage from the tool name and sibling list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('calculates the area') without mentioning any behavioral traits like error handling, input validation, or output format. This is inadequate for a tool with parameters and no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('计算梯形的面积') that is front-loaded and wastes no words. It directly states the purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple calculation with 3 parameters), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It does not cover parameter meanings, behavioral aspects, or output details, leaving significant gaps for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description does not add any meaning beyond the schema, failing to explain what 'top_base', 'bottom_base', and 'height' represent or their units. This leaves parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算梯形的面积' (calculates the area of a trapezoid) clearly states the verb ('calculates') and resource ('area of a trapezoid'), making the purpose specific and understandable. However, it does not distinguish from sibling tools like 'triangle_calculation' or 'rectangle_calculation' beyond the geometric shape, which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other area calculation tools (e.g., 'circle_calculation', 'triangle_calculation') or mathematical operations. It lacks explicit context, prerequisites, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool calculates without any information about how it behaves: no mention of error handling (e.g., for empty arrays), computational complexity, precision, or what the output format looks like. This is inadequate for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. While it's arguably too brief for completeness, as a standalone statement it's perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, how to interpret the 'sample' parameter, what format the 'numbers' array should be in, or any behavioral aspects. For a statistical calculation tool with parameters, this minimal description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter ('numbers' and 'sample') has descriptions in the schema. The tool description provides no information about parameters whatsoever - it doesn't mention that 'numbers' is an array of values or that 'sample' is a boolean flag for sample vs population variance calculation. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算数组的方差' (calculate the variance of an array) clearly states the verb ('计算' - calculate) and resource ('数组的方差' - variance of an array). It distinguishes this tool from siblings like 'mean', 'stdDev', and 'sum' which perform different statistical operations. However, it doesn't explicitly differentiate from 'stdDev' (standard deviation) which is mathematically related to variance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 variance is preferred over standard deviation ('stdDev') or other statistical measures like 'mean' or 'range'. There's no context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 but offers none. It doesn't mention what units are supported, whether the conversion is bidirectional, precision considerations, error handling, or what the output format will be. This is inadequate for a tool with 3 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. There's no wasted language or unnecessary elaboration, making it appropriately concise for a simple conversion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what units are supported, how to specify them, what the output looks like, or any behavioral aspects. This leaves the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so all 3 parameters are undocumented in the schema. The description provides no information about what 'value', 'from_unit', or 'to_unit' should contain, what units are valid, or any format requirements. It fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '在不同体积单位之间进行转换' clearly states the tool's purpose as converting between volume units, which is a specific verb+resource combination. However, it doesn't differentiate from its sibling 'area_conversion' or other conversion tools, which would require mentioning it's specifically for volume units rather than area or other types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With sibling tools like 'area_conversion', 'length_conversion', and 'temperature_conversion', there's no indication that this is specifically for volume units or when volume conversion is needed versus other unit types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 but provides none. It doesn't mention whether the tool validates input constraints (like k ≤ n or non-negative integers), handles edge cases (like negative inputs), returns errors, or provides any information about the calculation method 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence that directly states the tool's purpose. There's zero wasted text, and the information is front-loaded with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical calculation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how it handles edge cases, mathematical constraints, or error conditions. The context signals indicate this is a non-trivial mathematical operation that needs more explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate but provides minimal parameter semantics. It mentions 'n choose k' which implies n and k are the standard binomial coefficient parameters, but doesn't explain their mathematical meaning, valid ranges beyond the schema's technical limits, or what happens with invalid combinations (like k > n).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '计算二项式系数 (n choose k)', which translates to 'calculate binomial coefficient (n choose k)'. This specifies the exact mathematical operation and identifies the two parameters (n and k). However, it doesn't explicitly differentiate from sibling tools like 'combination' which might serve a similar mathematical purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of when this tool is appropriate, what mathematical scenarios it applies to, or how it differs from related sibling tools like 'combination' or 'permutation' in the same server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 but provides none. It doesn't mention whether the tool accepts negative inputs (cube roots of negative numbers are real), what happens with non-numeric inputs, error handling, precision, or return format. The single sentence only states the mathematical operation without any implementation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese sentence that directly states the tool's purpose. There's zero wasted verbiage or unnecessary elaboration. For a simple mathematical function, this level of brevity is appropriate and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 inadequate. It doesn't explain the return value format, error conditions, numerical precision, or edge cases. While cube root is mathematically straightforward, the description provides insufficient context for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'a', and the tool description provides no parameter information whatsoever. It doesn't explain what 'a' represents, its valid range, or units. While this is a simple mathematical function, the description fails to add any semantic value beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '计算数字的立方根' (calculate the cube root of a number), which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'sqrt' (square root) and 'nthRoot' (general nth root) by focusing specifically on cube roots. However, it doesn't explicitly mention how it differs from 'nthRoot' with n=3, which would make it a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of when to choose 'cbrt' over 'nthRoot' with n=3, or whether it handles negative numbers differently than 'power' with exponent 1/3. The agent must infer usage from the name and sibling context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the calculation purpose without mentioning critical behaviors: it doesn't warn about division by zero (when b_real and b_imag are both zero), describe error handling, specify output format (e.g., real and imaginary parts), or note mathematical constraints. This is inadequate for a mutation-like operation (division) with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('计算两个复数的商') that directly states the purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste—every word earns its place by conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mathematical operation with 4 parameters), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks behavioral details (e.g., error cases like division by zero), parameter explanations, output information, and usage guidelines. For a tool performing division on complex numbers, this minimal description is insufficient to ensure correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds minimal value by implying parameters represent two complex numbers (a and b), but doesn't explain that 'a_real', 'a_imag', 'b_real', and 'b_imag' correspond to real and imaginary components, their units, or valid ranges. It fails to compensate for the coverage gap, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算两个复数的商' (calculates the quotient of two complex numbers) clearly states the verb (calculates) and resource (two complex numbers). It distinguishes from sibling tools like 'complex_add' or 'complex_multiply' by specifying division. However, it doesn't explicitly mention the mathematical operation name 'division' beyond '商' (quotient), which is slightly less specific than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites (e.g., avoiding division by zero), compare to sibling tools like 'divide' (for real numbers) or 'complex_multiply', or specify contexts where complex division is appropriate. Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does without any additional context about its behavior, such as error handling, performance characteristics, or output format. This leaves significant gaps in understanding how the tool operates beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence: '计算两个复数的乘积'. It is front-loaded and wastes no words, making it easy to parse quickly. Every part of the sentence directly contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mathematical operation with four parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the input parameters, expected output format, or any behavioral traits. For a tool with this level of detail required, the description falls short in providing enough context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the four parameters (a_real, a_imag, b_real, b_imag) are documented in the schema. The description does not compensate by explaining what these parameters represent (e.g., real and imaginary parts of two complex numbers). This lack of semantic information makes it difficult for an agent to understand how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算两个复数的乘积' (calculates the product of two complex numbers). It specifies the verb '计算' (calculate) and resource '两个复数的乘积' (product of two complex numbers), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like complex_add, complex_divide, or complex_subtract, which is why it doesn't achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any prerequisites, context for use, or comparisons to sibling tools such as complex_add or complex_divide. Without this information, the agent lacks direction on selecting this tool appropriately among similar options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does mathematically without any information about error handling, precision, performance characteristics, or what the output format will be. For a computational tool with no annotation coverage, this is a significant gap in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. For a simple mathematical operation, this level of conciseness is appropriate and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a computational tool with 4 parameters (0% schema coverage), no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the parameter structure, doesn't describe the output format, and provides no behavioral context. For a tool that performs mathematical operations, users need to understand how complex numbers are represented and what the result format will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, and the description provides no information about what these parameters represent. The description mentions '两个复数' (two complex numbers) but doesn't explain that complex numbers are represented as separate real and imaginary components (a_real, a_imag, b_real, b_imag). The description fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算两个复数的差' (calculates the difference of two complex numbers) clearly states the verb ('计算' - calculate) and resource ('两个复数的差' - difference of two complex numbers). It's specific about what mathematical operation it performs, though it doesn't explicitly distinguish from sibling tools like 'complex_add' or 'subtract' beyond the 'complex' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are multiple sibling tools for mathematical operations (including 'complex_add', 'subtract', and general arithmetic tools), but the description doesn't indicate when complex subtraction is specifically needed or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does mathematically, with no information about constraints (e.g., matrix dimensions must match), error conditions, performance characteristics, or output format. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 no wasted language or unnecessary elaboration - it's appropriately sized for a basic mathematical operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical operation tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It doesn't explain the mathematical constraints (matrices must have same dimensions), error handling, return format, or how this differs from similar operations. The context demands more complete documentation than what's provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'two matrices' which corresponds to the two parameters, but adds no semantic details about expected format (e.g., 2D arrays), constraints (e.g., must be same dimensions), or data types. This minimal information doesn't adequately compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算两个矩阵的和' (calculates the sum of two matrices) clearly states the verb (calculate sum) and resource (two matrices). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'matrix_subtract' or 'complex_add' beyond the mathematical operation name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are multiple matrix operations (matrix_subtract, matrix_multiply, matrix_determinant) and general mathematical operations (add, complex_add) in the sibling list, but the description doesn't indicate when matrix addition is appropriate versus other operations or tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. The description only states what the tool calculates, with no information about error handling (e.g., empty arrays, non-numeric elements), performance characteristics, return format, or computational limitations. For a mathematical tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple mathematical operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical simplicity, no annotations, no output schema, and minimal parameter documentation, the description is incomplete. While the core operation is clear, it lacks information about input validation, error conditions, return format, and practical usage considerations that would help an agent invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with only one parameter 'numbers' of type array with unspecified items. The description mentions '数组' (array) but provides no additional semantic information about what the array should contain (e.g., numeric values only), acceptable formats, or constraints. It partially compensates for the schema gap by identifying the parameter type but lacks crucial details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算数组的算术平均值' (calculate the arithmetic mean of an array) clearly states the verb ('计算' - calculate) and resource ('数组的算术平均值' - arithmetic mean of an array). It distinguishes from siblings like 'median', 'mode', 'sum', and 'stdDev' by specifying the arithmetic mean operation. However, it doesn't explicitly differentiate from similar statistical tools beyond naming the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 to choose 'mean' over 'median' or 'mode' for central tendency measurement, nor does it specify prerequisites or appropriate contexts. The agent must infer usage from the mathematical operation alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does ('find the minimum value') without any information about error handling (e.g., empty arrays, non-numeric elements), performance characteristics, return format, or any other behavioral traits. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states the tool's function. There's no wasted language or unnecessary elaboration, making it easy to parse and understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It states the basic purpose but lacks crucial information about parameter requirements, return values, error conditions, and behavioral characteristics that would be needed for an AI agent to use this tool effectively and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one parameter 'numbers' of type array with unspecified items. The description mentions '数组' (array) but provides no additional semantic context about what the array should contain (e.g., numeric values only), format expectations, or constraints. While it implies the parameter is an array, this doesn't compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '找出数组中的最小值' (find the minimum value in an array) clearly states the tool's function with a specific verb ('find') and resource ('array'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from its sibling 'max' (which finds the maximum value), though the names themselves provide some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools performing mathematical operations (like 'max', 'mean', 'median'), there's no indication of when 'min' is appropriate versus other statistical tools or how it relates to them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The description only states what the tool calculates without any behavioral information: no mention of input constraints (e.g., domain restrictions), output format, precision, error handling, or mathematical properties. This is inadequate for a computational tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese phrase that directly states the tool's purpose. There's zero wasted verbiage or unnecessary elaboration. It's appropriately sized for a simple mathematical function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical function with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address behavioral aspects, parameter meaning, output format, or usage context. While the tool is conceptually simple, the description leaves too many gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The description adds no parameter information beyond what the schema provides - it doesn't explain what 'value' represents (input angle/argument), units (radians/degrees), valid ranges, or special cases. With one undocumented parameter, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算双曲正切值' (calculates hyperbolic tangent value) clearly states the verb (calculate) and resource (hyperbolic tangent value). It distinguishes from siblings like 'tan' (tangent) and 'sinh' (hyperbolic sine) by specifying the hyperbolic tangent function. However, it doesn't explicitly mention the mathematical function name 'tanh' which would make it fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mathematical contexts, comparison with regular tangent ('tan'), or when hyperbolic functions are appropriate. With many sibling mathematical tools, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool calculates but provides no information about computational complexity, handling of large values, error conditions, return format, or performance characteristics. For a mathematical computation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's front-loaded with the core functionality and doesn't bury important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a computational tool with no annotations, no output schema, and minimal parameter documentation, the description is insufficient. It doesn't explain what the tool returns (a single number? formatted string?), doesn't mention performance considerations for large n values, and doesn't differentiate from the similar 'fibonacciSequence' tool. For a tool that performs mathematical computation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema. It clarifies that parameter 'n' represents the position in the Fibonacci sequence, which is helpful since schema description coverage is 0%. However, it doesn't explain what values of 'n' are valid (though the schema shows integer range), whether n starts at 0 or 1, or how negative values might be handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算斐波那契数列的第n项' (calculates the nth term of the Fibonacci sequence). It specifies both the verb (calculate) and resource (nth term of Fibonacci sequence), making the function unambiguous. However, it doesn't differentiate from its sibling 'fibonacciSequence', which appears to calculate the entire sequence rather than a single term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the sibling tool 'fibonacciSequence' or explain that this tool returns a single term while the sibling returns a sequence. There's no context about appropriate use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action (calculate determinant) but doesn't disclose behavioral traits such as error handling (e.g., for non-square or singular matrices), computational complexity, or output format. This is a significant gap for a mathematical tool with potential edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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. It is appropriately sized and front-loaded with zero wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mathematical operation with potential errors), no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on parameter requirements, behavioral constraints, and output format, which are essential for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the single parameter 'matrix'. It doesn't specify that the matrix must be square, its expected format (e.g., 2D array), or constraints (e.g., numeric values). The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算方阵的行列式' (calculates the determinant of a square matrix) clearly states the verb (calculate) and resource (determinant of square matrix). It distinguishes from siblings like matrix_inverse or matrix_trace by specifying the determinant operation, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., matrix must be square), when not to use it (e.g., for non-square matrices), or suggest sibling tools for related operations like matrix_inverse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does mathematically, with no information about error handling (e.g., division by zero), performance characteristics, rate limits, authentication needs, or what happens with non-integer inputs. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple mathematical operation and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical operation tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It explains the mathematical purpose but lacks crucial context about parameter roles, error conditions, return format, and behavioral characteristics that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description adds some value by implying 'a' and 'b' are the two numbers for the modulo operation. However, it doesn't specify which is dividend vs divisor, expected data types beyond 'number', or handling of edge cases. The description partially compensates but doesn't fully address the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算两个数的余数' (calculates the remainder of two numbers) clearly states the tool's function with a specific verb ('计算' - calculate) and resource ('两个数的余数' - remainder of two numbers). It distinguishes itself from siblings like 'divide' or 'gcd' by focusing specifically on the modulo operation, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many mathematical operation siblings (like 'divide', 'gcd', 'lcm'), there's no indication of when modulo is appropriate versus other division-related operations or when it might be preferred in specific contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the calculation without mentioning potential issues like handling of large numbers, negative bases with non-integer exponents, overflow, or error conditions. This is inadequate for a mutation-like mathematical tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function with zero wasted words. It's appropriately sized for this simple mathematical operation and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical tool with no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks behavioral context (e.g., error handling), output format details, and usage guidelines, making it insufficient for reliable agent invocation despite the simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by naming parameters a and b and specifying their roles (base and exponent). However, it doesn't provide details like valid ranges (e.g., b can be negative or fractional) or examples, leaving gaps compared to the schema's minimal type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算a的b次方' (calculates a to the power of b) clearly states the mathematical operation with specific parameters a and b. It distinguishes from siblings like 'multiply' or 'sqrt' by specifying exponentiation, though it doesn't explicitly differentiate from potential similar tools (none present in siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description only states what it does, not when it's appropriate compared to other mathematical operations in the sibling list (e.g., 'nthRoot' for roots or 'multiply' for multiplication).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '计算' (calculate) implies a read-only operation, the description doesn't disclose any behavioral traits such as error handling (e.g., what happens with non-numeric input), performance characteristics, or whether it works with integers, floats, or complex numbers. It provides only the basic operation without context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple mathematical function and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mathematical tool with 1 parameter and no output schema, the description is incomplete. It doesn't explain the return value (absolute value as a number), error conditions, or mathematical properties. While the operation is conceptually simple, the description lacks context about implementation details that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for undocumented parameters. The description mentions '数字' (number) which aligns with parameter 'a' of type number, but doesn't explain what 'a' represents, valid ranges, or special cases (e.g., negative numbers, zero, infinity). With 1 parameter and 0% schema coverage, this minimal information is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算数字的绝对值' (calculates the absolute value of a number) clearly states the verb ('计算' - calculate) and resource ('绝对值' - absolute value). It distinguishes from siblings by specifying the mathematical operation, though it doesn't explicitly differentiate from similar mathematical functions like 'abs' vs 'cbrt' or 'sqrt'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling mathematical tools (e.g., 'sqrt', 'cbrt', 'sin', 'cos'), there's no indication of when absolute value calculation is appropriate versus other mathematical operations or when other tools might be better suited for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the output unit (radians) but lacks critical behavioral details: input constraints (e.g., value range -1 to 1), error handling for invalid inputs, precision/rounding behavior, or whether it handles complex numbers. For a mathematical function with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one phrase) and front-loaded with the core purpose. Every word earns its place: '计算反余弦值' defines the operation, and '（返回弧度）' adds crucial output unit information. No wasted words or redundant structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers the basic operation and output units but misses input constraints, error conditions, precision details, and mathematical context needed for reliable use. For a mathematical function with behavioral nuances, this leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 no parameter semantics beyond the schema's generic 'value' parameter. The description doesn't explain what 'value' represents (e.g., cosine value between -1 and 1), its expected format, or units. With 1 undocumented parameter, the description fails to provide meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算反余弦值（返回弧度）' translates to 'calculate arccosine (returns radians)'. It specifies both the mathematical operation (arccosine) and the output unit (radians), which distinguishes it from potential degree-based alternatives. However, it doesn't explicitly differentiate from sibling tools like 'asin' or 'atan' beyond the mathematical function name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the input domain (e.g., value must be between -1 and 1 for real arccosine), nor does it reference sibling tools like 'acos' vs 'acosh' (inverse hyperbolic cosine) or 'radToDeg' for unit conversion. Usage is implied by the mathematical function name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While it mentions the output is in radians, it doesn't disclose critical behavioral traits: valid input range (typically -1 to 1 for arcsine), error handling for invalid inputs, precision limitations, or whether it's a pure mathematical function. The description is minimal and lacks necessary operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states the operation and output format. There's no wasted language or unnecessary elaboration, making it efficiently front-loaded with the core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical function with no annotations and no output schema, the description is incomplete. It lacks information about input domain restrictions, error conditions, precision, and doesn't explain the relationship to sibling trigonometric functions. The minimal description doesn't provide enough context for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the single parameter 'value'. It doesn't explain what 'value' represents (e.g., sine value between -1 and 1), units, or constraints. With one undocumented parameter, the description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算反正弦值（返回弧度）' translates to 'calculate arcsine (returns radians)'. This specifies both the mathematical operation (arcsine) and the output unit (radians). However, it doesn't differentiate from sibling tools like 'asin' vs 'asinh' or 'sin' beyond the basic function name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling mathematical functions (e.g., 'asin', 'asinh', 'sin', 'acos'), there's no indication of appropriate contexts, input domain restrictions, or comparisons to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool calculates arctangent and returns radians, which covers the basic operation. However, it doesn't disclose important behavioral traits like input domain restrictions (e.g., valid ranges for 'value'), error handling for invalid inputs, precision, or output format. For a mathematical function with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence in Chinese that directly states the tool's function and output unit. There's zero wasted text, and every word earns its place by conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical nature, no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover parameter details, output format beyond 'radians', error conditions, or mathematical context. While simple tools might need less, this leaves too many gaps for reliable agent use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one parameter 'value' of type number. The description doesn't add any parameter semantics beyond implying it's the input for arctangent calculation. It doesn't explain what 'value' represents (e.g., tangent ratio, numeric input), valid ranges, or units. With low schema coverage, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算反正切值' (calculate arctangent value) with the specific detail that it returns radians. This distinguishes it from tools like 'atan2' (two-argument arctangent) and 'atanh' (inverse hyperbolic tangent) in the sibling list. However, it doesn't explicitly differentiate from 'atan2' beyond the parameter count, which is why it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'atan2' or 'atanh'. It doesn't mention the single-argument limitation compared to 'atan2' or the mathematical context for choosing between trigonometric functions. There's only a basic functional statement without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the bisection method but doesn't explain key behaviors: that it requires the function to have opposite signs at the bounds, that it's an iterative method with convergence guarantees under certain conditions, what happens when max_iterations is reached, or what format the output takes. This is inadequate for a numerical method tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a numerical method tool with 6 parameters (4 required), no annotations, no output schema, and 0% schema description coverage, this description is severely incomplete. It doesn't explain the mathematical assumptions, parameter meanings, convergence criteria, error handling, or output format - all critical for proper use of a bisection method implementation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 6 parameters, the description provides no information about what 'function_type', 'coefficients', 'left_bound', 'right_bound', 'tolerance', or 'max_iterations' mean or how they should be used. The description doesn't compensate for this complete lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: '使用二分法求解方程在区间内的根' (Use the bisection method to find the root of an equation within an interval). It specifies the verb ('求解' - solve/find) and resource ('方程' - equation/root), but doesn't distinguish it from sibling tools like 'newton_method' which serves a similar mathematical purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'newton_method' or other root-finding approaches. The description only states what it does, not when it's appropriate or what prerequisites exist (e.g., function must be continuous with opposite signs at bounds).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the calculation purpose without mentioning any behavioral traits such as whether it's a read-only operation, if it has side effects, performance considerations, or error handling. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence: '计算债券的理论价格'. It is front-loaded and wastes no words, making it efficient for quick understanding. However, this conciseness comes at the cost of completeness, as noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial calculation tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It lacks details on parameter meanings, usage context, behavioral traits, and expected outputs, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The tool description does not add any semantic information about the parameters (e.g., what 'face_value' or 'coupon_rate' represent, their units, or typical ranges). This forces the agent to guess parameter meanings, which is inadequate given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算债券的理论价格' (calculate the theoretical price of a bond). It specifies the verb '计算' (calculate) and the resource '债券的理论价格' (theoretical price of a bond), making the intent unambiguous. However, it does not differentiate from siblings like 'net_present_value' or 'present_value_annuity', which might also involve financial calculations, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention any context, prerequisites, or exclusions, and with siblings like 'net_present_value' and 'present_value_annuity' that could overlap in financial contexts, the agent is left without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the mathematical operation but doesn't disclose behavioral traits like error handling (e.g., for invalid inputs), performance characteristics, or output format. For a mathematical tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the purpose. It's appropriately sized and front-loaded with zero wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema description coverage for a 4-parameter tool, the description is incomplete. It lacks details on parameter meanings, output format, error conditions, or usage context, leaving the agent with insufficient information for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions '两个复数' (two complex numbers) which implies four parameters (real and imaginary parts), but doesn't explain the parameter names (a_real, a_imag, etc.) or their semantics. The description adds minimal value beyond what's inferable from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算两个复数的和' (calculates the sum of two complex numbers) clearly states the verb (calculate sum) and resource (complex numbers). It distinguishes from sibling tools like 'complex_subtract' by specifying addition, but doesn't explicitly differentiate from generic 'add' which might handle other data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention when complex addition is needed versus other mathematical operations, nor does it reference sibling tools like 'complex_subtract' or 'add' for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 but provides minimal information. It states what the tool calculates but doesn't describe the mathematical formula used, units for parameters, typical output format, error conditions, or computational characteristics. For a financial calculation tool with 4 parameters, this leaves significant behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one Chinese sentence ('计算复利投资的未来价值'). It's front-loaded with the core purpose and contains no wasted words. While it may be too brief for adequate documentation, it achieves perfect conciseness within its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter financial calculation tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain the mathematical model, parameter semantics, return format, or usage context. The agent would need to guess parameter meanings and the calculation approach, which is inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 4 parameters, the description provides no parameter information whatsoever. It doesn't explain what 'principal', 'annual_rate', 'periods', or 'compounding_frequency' represent, their expected units (e.g., percentage vs decimal for rate), or how they interact in the calculation. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '计算复利投资的未来价值' (calculate the future value of compound interest investment), which is a specific verb+resource combination. It distinguishes itself from siblings like 'future_value_annuity' by focusing specifically on compound interest rather than annuities. However, it doesn't explicitly differentiate from other financial calculation tools like 'bond_price' or 'net_present_value' beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of when compound interest calculations are appropriate compared to simple interest (not in sibling list) or other financial tools like 'future_value_annuity' or 'net_present_value'. The user must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '计算' (calculate) implies a read-only operation, the description doesn't specify whether this is a pure computation, what units are used, precision considerations, or error handling. It lacks details about the return format or any computational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's front-loaded with the essential information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a computational tool with 2 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (just volume and surface area, but in what format?), doesn't mention parameter requirements, and provides no context about the mathematical formulas or assumptions used in the calculations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description doesn't mention parameters at all. While the parameter names ('radius', 'height') are self-explanatory for cone calculations, the description provides no additional semantic context about expected units, valid ranges, or the relationship between these parameters in the calculations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算圆锥体的体积和表面积' (calculates the volume and surface area of a cone). It specifies both the resource (cone) and the operations (volume and surface area calculations). However, it doesn't explicitly differentiate from sibling tools like 'sphere_calculation' or 'cylinder_calculation' beyond the different geometric shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 to choose this over other geometric calculation tools like 'sphere_calculation' or 'cylinder_calculation', nor does it specify any prerequisites or contextual constraints for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool calculates volume and surface area, implying a read-only computation, but doesn't specify units, precision, error handling, or output format. For a mathematical tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '计算圆柱体的体积和表面积'. It's front-loaded with the core purpose and contains no unnecessary words, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical nature, 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover parameter meanings, units, calculation formulas, or output structure (e.g., whether it returns both values as a single object). For a calculation tool, this lack of detail could lead to misuse or incorrect assumptions by the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (radius, height) with 0% description coverage, meaning the schema provides no semantic context. The description doesn't mention these parameters at all, failing to compensate for the schema's lack of documentation. It doesn't explain what 'radius' and 'height' represent or their expected units (e.g., meters, centimeters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算圆柱体的体积和表面积' (calculate the volume and surface area of a cylinder). This specifies both the verb (calculate) and resource (cylinder), making it unambiguous. However, it doesn't differentiate from sibling tools like 'sphere_calculation' or 'cone_calculation' beyond naming the geometric shape, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any prerequisites, exclusions, or comparisons to sibling tools like 'circle_calculation' or 'sphere_calculation'. The agent must infer usage based on the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool counts divisors for positive integers, but doesn't disclose behavioral traits like: what happens with negative or zero inputs (schema allows negative integers), performance characteristics, error handling, or output format. The description is minimal and lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence that directly states the tool's purpose. No wasted words or unnecessary elaboration. Perfectly front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical function with no annotations and no output schema, the description is insufficient. It doesn't explain the return value format, edge cases (like input 0 or 1), mathematical definition of 'divisors', or how it relates to sibling tools. The context signals show 1 parameter with 0% schema coverage, making the minimal description inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The description mentions '正整数' (positive integer) which adds semantic meaning beyond the schema's generic integer type with range -2147483648 to 2147483647. However, it doesn't explain the parameter 'n' explicitly or provide examples, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算正整数的因子个数' (count the number of divisors of a positive integer) clearly states the verb ('计算' - calculate/count) and resource ('正整数的因子个数' - divisors of a positive integer). It distinguishes from sibling 'divisorList' which likely lists divisors rather than counting them. However, it doesn't specify the mathematical method or edge cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'divisorList' (which appears to be a sibling tool) or other mathematical functions. The description implies it's for counting divisors of positive integers, but doesn't explicitly state when this is preferred over listing divisors or other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '列出' (list) implies a read-only operation, it doesn't specify output format, ordering of results, handling of edge cases (like n=0 or negative n despite '正整数' suggesting positive integers), or performance characteristics. The description adds minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese sentence that states the tool's purpose without any wasted words. It's appropriately sized for this simple mathematical function and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what format the divisor list returns in (array, string, etc.), doesn't address edge cases, and provides minimal guidance for proper use. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions '正整数' (positive integer) which adds semantic context beyond the schema's generic integer type with wide range (-2147483648 to 2147483647). However, it doesn't explain what happens with non-positive inputs or provide examples of valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('列出' - list) and the resource ('正整数的所有因子' - all divisors of a positive integer). It specifies the mathematical operation precisely, though it doesn't explicitly differentiate from sibling tools like divisorCount (which likely counts divisors rather than listing them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of sibling tools like divisorCount, primeFactorization, or isPrime that might be relevant for related mathematical operations. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states what the tool does but provides no information about error handling (e.g., what happens with non-integer inputs, negative numbers, or empty arrays), performance characteristics, or output format. The description is purely functional without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for this simple mathematical tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It doesn't explain what format the result will be in (single integer? array?), doesn't mention error conditions, and provides minimal parameter guidance. Given the mathematical context and sibling tools, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for undocumented parameters. The description mentions '两个或多个整数' (two or more integers), which implies the 'numbers' parameter should contain integers, but doesn't specify array format, constraints, or provide examples. This adds minimal semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算两个或多个整数的最大公约数' (calculates the greatest common divisor of two or more integers). It specifies the verb (calculate) and resource (GCD of integers), but doesn't differentiate from sibling 'lcm' (least common multiple) tool, which serves a related mathematical function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While the mathematical purpose is clear, there's no mention of when to choose gcd over other mathematical operations or how it relates to sibling tools like 'lcm' for complementary number theory calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool calculates IRR but doesn't disclose behavioral traits such as numerical method used (e.g., Newton's method), convergence behavior, error handling, or output format. For a financial calculation tool with 5 parameters, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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. It's front-loaded with no wasted words, making it highly concise and well-structured for its minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial calculation with 5 parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't provide enough context for an AI agent to understand how to use the tool effectively, missing details on behavior, parameters, and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description doesn't add any parameter semantics—it doesn't explain what 'initial_investment', 'cash_flows', 'initial_guess', 'tolerance', or 'max_iterations' mean or how they affect the calculation. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算投资项目的内部收益率（IRR）' translates to 'Calculate the internal rate of return (IRR) of an investment project.' It specifies the verb (calculate) and resource (IRR), but doesn't distinguish it from siblings like 'net_present_value' or 'future_value_annuity' that also perform financial calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or comparisons to sibling tools like 'net_present_value' or 'bisection_method' (which might be related algorithms). Usage is implied only by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the input must be a positive integer, but doesn't disclose behavioral traits such as performance characteristics (e.g., handling large numbers), error handling for non-positive inputs, or the return format (e.g., boolean or structured result).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. It's front-loaded with no unnecessary words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical nature, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on return values, error conditions, and performance limits, which are important for an agent to use it correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 that 'n' must be a positive integer, which clarifies beyond the schema's broad integer range (-2147483648 to 2147483647). However, it doesn't explain edge cases (e.g., 1 or 2) or validation details, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '判断一个正整数是否为素数' (determine if a positive integer is prime). It specifies the verb (determine) and resource (positive integer), though it doesn't explicitly differentiate from siblings like 'isPerfectNumber' or 'primeFactorization' beyond the obvious semantic difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'isPerfectNumber' for other number properties or 'primeFactorization' for detailed prime analysis, nor does it specify prerequisites or constraints beyond the positive integer requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose error conditions (e.g., mismatched array lengths, duplicate x-points), computational complexity, numerical stability issues, or what happens with invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a mathematical function tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical computation tool with 3 undocumented parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the mathematical context, assumptions, return format, or error handling needed for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. It doesn't explain that x_points and y_points must be arrays of equal length representing known data points, or that interpolation_point is where to evaluate the interpolating polynomial. The three parameters remain undocumented beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the mathematical method (Lagrange interpolation) and the action (calculates function values at interpolation points). It specifies the verb 'calculate' and resource 'function values', but doesn't differentiate from sibling interpolation methods like 'bisection_method' or 'newton_method' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, limitations, or comparison with other interpolation/numerical methods available in the sibling tools list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what the tool does (calculates LCM) but doesn't disclose behavioral traits like error handling for non-integer inputs, performance characteristics, maximum array size, or what happens with empty/insufficient input arrays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for this simple mathematical function and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical calculation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain the return format, error conditions, or provide examples. The agent would need to guess about the output structure and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions '两个或多个整数' (two or more integers) which implies the 'numbers' parameter should contain integers, but doesn't specify format constraints, minimum array length, or handling of edge cases. This adds some meaning but insufficiently compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算两个或多个整数的最小公倍数' (calculates the least common multiple of two or more integers). It specifies the verb (calculate) and resource (LCM of integers), but doesn't differentiate from siblings like 'gcd' which is a related but different mathematical operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'gcd' (greatest common divisor) or explain when LCM calculation is appropriate versus other mathematical operations available in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the calculation purpose but does not disclose any behavioral traits such as input validation, error handling, output format, or computational limitations. For a financial calculation tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance. Every part of the sentence earns its place by clearly defining the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial calculation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It adequately states what the tool does but lacks essential details such as parameter explanations, behavioral context, and output information, which are necessary for effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage, so the schema provides no semantic information. The description does not add any meaning beyond the schema; it does not explain what 'loan_amount', 'annual_rate', or 'years' represent, their units, or valid ranges. This fails to compensate for the low schema coverage, leaving parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算等额本息贷款的月供金额' (calculate the monthly payment amount for an equal principal and interest loan). It specifies the verb '计算' (calculate) and the resource '等额本息贷款的月供金额' (monthly payment for an equal principal and interest loan), making the function unambiguous. However, it does not explicitly differentiate from siblings like 'compound_interest' or 'future_value_annuity', which are related financial calculations but not identical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention any prerequisites, context for application, or comparison with sibling tools such as 'compound_interest' or 'present_value_annuity', which might be relevant for different loan or investment scenarios. Usage is implied by the tool's name and description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the mathematical operation but doesn't disclose behavioral traits like error handling (e.g., for negative values or base=1), precision, return format, or computational complexity. For a mathematical tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple mathematical function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical complexity (logarithm function), lack of annotations, and no output schema, the description is incomplete. It doesn't cover error conditions, return values, or usage context, leaving the agent to guess behavioral aspects. For a tool with two required parameters and no structured guidance, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions '指定底数' (specified base) which implies the 'base' parameter, and '对数' (logarithm) implies the 'value' parameter, but doesn't explain their roles, valid ranges (e.g., base > 0, base ≠ 1), or mathematical relationships. This adds minimal semantic value beyond the schema's parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the mathematical operation: '计算以指定底数的对数' (calculates the logarithm with a specified base). It specifies both the verb (calculate) and resource (logarithm), distinguishing it from sibling tools like ln (natural log) and log10 (base-10 log). However, it doesn't explicitly differentiate from these siblings beyond the base specification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like ln or log10. It doesn't mention typical use cases (e.g., base-2 for binary calculations, base-e for natural logs) or prerequisites. The agent must infer usage from the mathematical function alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the computation but doesn't disclose critical traits: whether it handles only numeric matrices, error behavior for singular matrices, computational complexity, or output format. For a mathematical operation with potential failures, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 without any fluff. It's front-loaded and wastes no words, making it easy to parse quickly despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of matrix inversion (which can fail for singular matrices) and the lack of annotations (0% coverage) and output schema, the description is insufficient. It doesn't address error handling, input constraints, or output format, leaving the agent without necessary context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information beyond the generic term 'matrix'. It doesn't specify that the matrix must be square, numeric, or invertible, nor does it explain the array structure (e.g., 2D array representation). With one undocumented parameter, the description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算方阵的逆矩阵' (computes the inverse of a square matrix) clearly states the verb ('计算' - compute) and resource ('方阵的逆矩阵' - inverse of a square matrix). It distinguishes from siblings like matrix_determinant or matrix_transpose by specifying the inverse operation. However, it doesn't explicitly mention that the input must be a square matrix (though implied by '方阵'), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the purpose is clear, there's no mention of prerequisites (e.g., matrix must be invertible), error conditions, or comparisons with other matrix operations like matrix_determinant for checking invertibility. The description assumes context without explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose error conditions (e.g., non-square matrices), computational complexity, or output format. The description is minimal and lacks transparency about how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 with zero wasted words. It's appropriately sized for a simple mathematical operation and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical tool with 1 parameter, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't address input constraints (square matrix requirement), error handling, or return value format, leaving significant gaps for an AI agent to understand proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 but adds no parameter information. It doesn't explain that 'matrix' must be a square 2D array, specify element types, or provide examples. The description fails to add meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '计算' (calculate) and the resource '方阵的迹' (trace of a square matrix), providing a specific mathematical operation. It distinguishes from siblings like matrix_determinant or matrix_inverse by focusing on trace calculation, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., input must be a square matrix), when not to use it, or refer to sibling tools like matrix_determinant for different matrix operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool does but doesn't disclose behavioral traits like error handling (e.g., what happens with empty arrays or non-numeric elements), performance characteristics, or return format. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. It's front-loaded with no wasted words, making it highly concise and well-structured for its simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no annotations, no output schema), the description is incomplete. It doesn't cover parameter details, error cases, or return values. While concise, it lacks necessary context for reliable use, especially with 0% schema coverage and no behavioral disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions 'array' which aligns with the 'numbers' parameter, but doesn't explain the parameter's semantics (e.g., that it expects numeric values, handles mixed types, or requires non-empty arrays). The description adds minimal value beyond the schema's structural information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '找出数组中的最大值' (find the maximum value in an array) clearly states the tool's purpose with a specific verb ('find') and resource ('array'), and it distinguishes from sibling tools like 'min' (which finds the minimum). However, it doesn't explicitly mention that it operates on numeric arrays, though this is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'min' for finding minimum values, 'mean' for averages, or other statistical functions. There's no context about appropriate use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the method but doesn't describe key behaviors: convergence properties (may fail for poor initial guesses), iteration limits, tolerance handling, or output format. For a numerical method with 5 parameters, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a numerical root-finding method with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't address convergence behavior, error handling, output format, or parameter semantics, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 but provides no parameter information. It doesn't explain what 'function_type', 'coefficients', 'initial_guess', 'tolerance', or 'max_iterations' mean or how they interact. For a tool with 5 undocumented parameters, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '使用牛顿法求解方程的根' (use Newton's method to find the root of an equation), which specifies the verb (solve) and resource (equation root). It distinguishes from siblings like bisection_method by naming the specific numerical method, but doesn't explicitly differentiate beyond that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like bisection_method or other root-finding approaches. There's no mention of prerequisites (e.g., function differentiability), convergence conditions, or typical use cases where Newton's method is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the computational method but doesn't describe important behavioral aspects: what precision to expect, how step_size affects accuracy, whether the function must be continuous, what happens with invalid inputs, or what the output format will be. For a numerical computation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that states exactly what the tool does with zero wasted words. It's appropriately sized for a mathematical computation tool and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of numerical differentiation (requires understanding of numerical stability, step size selection, function representation) with no annotations, 0% schema coverage, and no output schema, the description is insufficient. It doesn't explain how functions are represented (via 'function_type' and 'coefficients'), what numerical method variations exist, what precision to expect, or what the output looks like. For a tool with 4 parameters and mathematical complexity, this leaves too many unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all 4 parameters are undocumented in the schema. The description mentions '函数' (function) and '点' (point), which partially explains 'function_type' and 'point', but doesn't explain 'coefficients' (what format? polynomial coefficients?), 'step_size' (default value? typical range?), or the relationship between parameters. The description adds minimal value beyond what can be inferred from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('计算函数在某点的导数' - compute derivative of function at a point) and specifies the method ('使用中心差分法' - using central difference method). It distinguishes from siblings like 'newton_method' or 'bisection_method' by focusing specifically on numerical differentiation rather than root-finding or other numerical methods. However, it doesn't explicitly differentiate from potential similar tools that might not exist in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are no mentions of when this method is appropriate (e.g., for functions without analytical derivatives), when not to use it (e.g., for highly oscillatory functions), or what alternatives exist among the siblings. The agent must infer usage from the method name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the trapezoidal rule, which implies an approximation method with potential error, but does not disclose accuracy limitations, computational complexity, or error handling. The description lacks details on what the tool returns (e.g., a numerical value, error estimate) or any constraints like input validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of numerical integration with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It fails to explain parameter semantics, behavioral traits like accuracy or limitations, and what the tool returns, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for undocumented parameters. It does not explain any of the 5 parameters (function_type, coefficients, lower_bound, upper_bound, intervals), leaving their meanings, formats, and relationships unclear. For example, it does not clarify how 'function_type' and 'coefficients' define the function to integrate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '使用梯形法则计算函数的定积分' (Calculate the definite integral of a function using the trapezoidal rule). It specifies the verb (calculate), resource (definite integral), and method (trapezoidal rule), but does not differentiate from sibling tools like 'numerical_derivative' or 'bisection_method' beyond the mathematical operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention when numerical integration is preferred over analytical methods, or how it compares to other numerical methods available in the sibling list (e.g., 'newton_method' for root-finding). Usage is implied by the mathematical context but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states what the tool calculates but provides no information about how it behaves: no error conditions, no precision information, no assumptions about payment timing (beginning vs end of period), no mention of what happens with negative inputs, and no details about the return format. For a financial calculation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's front-loaded with the essential information, though that information is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial calculation tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, doesn't clarify parameter meanings, doesn't provide usage context, and doesn't disclose behavioral characteristics. The description leaves too many gaps for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the three parameters have descriptions in the schema. The tool description provides no parameter information whatsoever - it doesn't mention what 'payment', 'periods', or 'interest_rate' represent, their units, valid ranges beyond the schema's technical constraints, or how they relate to the calculation. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算普通年金的现值' (calculates the present value of an ordinary annuity). It specifies the verb (calculate) and resource (present value of ordinary annuity), which is clear and specific. However, it doesn't explicitly distinguish from its sibling 'future_value_annuity', which is a closely related financial calculation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of when this calculation is appropriate, what financial scenarios it applies to, or how it differs from related tools like 'future_value_annuity' or 'net_present_value'. The user must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool decomposes positive integers into prime factors, but doesn't describe output format (e.g., list of factors, exponents), handling of edge cases (e.g., n=1, negative numbers), performance characteristics, or error behavior. This leaves significant gaps for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical nature, no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return format, error handling, or behavioral details needed for reliable use. The description alone is insufficient for an agent to invoke the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description doesn't add any parameter-specific information. It implies 'n' should be a positive integer but doesn't clarify semantics beyond the schema's type and range. For a tool with low schema coverage, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '将正整数分解为素因数的乘积' (decompose positive integers into prime factors). It specifies the verb (decompose) and resource (positive integers), making the function unambiguous. However, it doesn't explicitly differentiate from siblings like 'isPrime' or 'divisorList', which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites (e.g., input must be positive), exclusions (e.g., not for non-integers), or comparisons to siblings like 'isPrime' for primality testing or 'divisorList' for listing all divisors. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states what the tool does (calculates product) but doesn't mention error handling (e.g., empty arrays, non-numeric elements), performance characteristics, or return format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple mathematical operation and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what happens with empty arrays, non-numeric inputs, overflow scenarios, or the return format. Given the context signals, more behavioral and parameter details would be needed for adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions '数组' (array) which aligns with the 'numbers' parameter, but provides no details about element types (numbers vs. other types), array size limits, or handling of special values. The description adds minimal semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算数组所有元素的乘积' (calculates the product of all elements in an array) clearly states the verb ('计算' - calculate) and resource ('数组所有元素的乘积' - product of all array elements). It distinguishes from siblings like 'sum' (which adds) or 'multiply' (which might handle pairwise multiplication), but doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 this tool is appropriate compared to 'multiply' (which appears to handle two numbers) or other mathematical operations in the sibling list. No context about input types or constraints is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '转换' (convert) implies a pure mathematical function, the description doesn't disclose any behavioral traits: no information about precision, error handling, input constraints (e.g., valid ranges), or output format. For a mathematical tool with no annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase that directly states the tool's function. There's zero wasted language, and it's front-loaded with the core purpose. For a simple conversion tool, this level of conciseness is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical conversion tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It doesn't explain what the tool returns (degrees as a number?), doesn't mention the conversion formula or precision, and doesn't address edge cases. The description should provide more context given the lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about the single parameter 'radians'. It doesn't specify what units are expected, valid ranges, or special cases. The description must compensate for the lack of schema documentation but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '将弧度转换为角度' (convert radians to degrees). It uses a specific verb ('转换' - convert) and specifies the resource (radians to degrees). However, it doesn't differentiate from its sibling tool 'degToRad' (degrees to radians), which performs the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With a sibling tool 'degToRad' that performs the inverse conversion, the description should ideally indicate this is for converting FROM radians TO degrees, not the reverse. No context about when this conversion is needed is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the calculation (max-min) but doesn't cover edge cases (e.g., empty arrays, non-numeric elements), error handling, or output format. For a tool with no annotations, this leaves significant gaps in understanding how it behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse quickly. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a simple mathematical tool), no annotations, no output schema, and low parameter coverage, the description is incomplete. It lacks details on behavior, parameters, and output, which are crucial for an agent to use it correctly. The description alone doesn't provide enough context for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description doesn't add any parameter details. It mentions '数组' (array) but doesn't specify element types (e.g., numbers), constraints, or examples. With low schema coverage, the description fails to compensate, leaving the parameter poorly defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算数组的范围（最大值-最小值）' (calculates the range of an array: maximum minus minimum). It specifies the verb '计算' (calculate) and the resource '数组的范围' (array's range), making it distinct from siblings like 'max', 'min', or 'variance'. However, it doesn't explicitly differentiate from tools like 'stdDev' or other statistical functions, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 scenarios like statistical analysis, data preprocessing, or comparisons with siblings such as 'variance' or 'stdDev'. Without any context on usage, the agent must infer based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does (calculates area and perimeter) but doesn't describe behavioral traits such as error handling (e.g., for invalid inputs like negative side lengths), computational limitations, or output format. For a calculation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: '计算正多边形的面积和周长'. It's front-loaded with the core purpose and has zero wasted words, making it highly concise and well-structured for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mathematical calculation tool), no annotations, no output schema, and low schema coverage (0%), the description is incomplete. It states the purpose but lacks details on parameters, behavior, outputs, or error conditions, which are essential for an AI agent to use it correctly in context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. With 0% schema description coverage and 2 parameters ('sides' and 'side_length'), the schema only provides types and constraints (e.g., integer for 'sides'). The description doesn't explain what these parameters represent (e.g., number of sides and length of each side) or their units, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算正多边形的面积和周长' (calculates the area and perimeter of a regular polygon). It specifies the verb ('计算' - calculate) and resource ('正多边形' - regular polygon) with the outputs (area and perimeter). However, it doesn't distinguish from siblings like 'circle_calculation' or 'triangle_calculation' beyond the polygon type, which is implicit but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites (e.g., needing a regular polygon), exclusions (e.g., not for irregular polygons), or comparisons to sibling tools (e.g., 'circle_calculation' for circles). Usage is implied by the name and purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool calculates a value but doesn't describe the return format (e.g., numeric result), error handling (e.g., for invalid inputs), or computational characteristics (e.g., precision, domain restrictions). For a mathematical function with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('计算双曲正弦值') that directly states the tool's purpose without any wasted words. It is appropriately sized for a simple mathematical function and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical nature, no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return value, input constraints, or how it fits within the broader set of mathematical tools. For a function with one parameter, more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, with one parameter 'value' of type 'number'. The description adds no information about what 'value' represents (e.g., input angle in radians, real number), acceptable ranges, or units. It fails to compensate for the lack of schema documentation, leaving the parameter's meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算双曲正弦值' (calculates hyperbolic sine value) clearly states the verb ('计算' - calculate) and resource ('双曲正弦值' - hyperbolic sine value). It distinguishes from siblings like 'sin' (sine) and 'cosh' (hyperbolic cosine) by specifying the hyperbolic sine function. However, it doesn't explicitly differentiate from 'asinh' (inverse hyperbolic sine), which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 hyperbolic sine is needed over regular sine ('sin') or other hyperbolic functions like 'cosh' or 'tanh', nor does it specify any prerequisites or context for usage. The agent must infer usage from the function name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the mathematical function without describing input validation (e.g., handling of non-numeric arrays), error conditions, return format, or computational characteristics (e.g., precision, performance). For a tool with two parameters and no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. It is front-loaded with the core purpose and contains no unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical complexity, lack of annotations, 0% schema coverage, and no output schema, the description is insufficient. It doesn't cover parameter meanings, behavioral traits, return values, or error handling, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions '数组' (array) which aligns with the 'numbers' parameter, but doesn't explain the 'sample' parameter (likely indicating sample vs population standard deviation) or provide any details on data types, constraints, or usage examples. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算数组的标准差' clearly states the tool's purpose as calculating the standard deviation of an array, which is a specific mathematical operation. It distinguishes from many siblings (e.g., 'mean', 'variance') by focusing on standard deviation, though it doesn't explicitly differentiate from closely related tools like 'variance' beyond the mathematical distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 to prefer 'stdDev' over 'variance' (a sibling tool) or other statistical functions, nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool calculates a sum but doesn't disclose behavioral traits such as error handling (e.g., for non-numeric elements), performance (e.g., for large arrays), or output format (e.g., returns a number). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. It is front-loaded with no wasted words, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description is incomplete. It lacks details on parameter constraints, error cases, return values, and behavioral context. For a mathematical tool among many siblings, more guidance on usage and limitations would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, with one parameter 'numbers' of type array. The description adds minimal semantics by implying the array contains elements to sum, but it doesn't specify element types (e.g., must be numbers), constraints (e.g., no empty arrays), or examples. It partially compensates but leaves key details undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算数组所有元素的和' (calculates the sum of all elements in an array) clearly states the verb (calculate sum) and resource (array elements). It distinguishes from siblings like 'add' (binary addition) and 'product' (multiplication), though it doesn't explicitly mention these distinctions. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'add' (for two numbers) or 'product' (for multiplication), nor does it specify use cases like aggregating numerical arrays versus other statistical tools (mean, median). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the conversion action but doesn't disclose behavioral traits like error handling (e.g., invalid units), precision, rounding, or output format. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. It's front-loaded with no wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on parameter usage, error conditions, return values, and behavioral context. For a 3-parameter tool with no structured support, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions the units involved (Celsius, Fahrenheit, Kelvin) but doesn't explain the parameters (value, from_unit, to_unit) or their semantics (e.g., valid unit strings, numeric ranges). This adds minimal value beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '在摄氏度、华氏度和开尔文之间进行转换' (convert between Celsius, Fahrenheit, and Kelvin). It specifies the verb (convert) and resources (temperature units), but doesn't explicitly differentiate from sibling conversion tools like area_conversion or length_conversion beyond the temperature domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, constraints, or comparisons with other conversion tools in the sibling list. It's a standalone statement without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions calculating '面积、周长等属性' (area, perimeter, and other properties), hinting at multiple outputs, but doesn't specify what '等属性' (other properties) includes, error conditions (e.g., invalid side lengths), or computational methods. This leaves gaps for a mutation-free calculation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. It's front-loaded with the core purpose and avoids unnecessary words, making it appropriately concise for a simple calculation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on output format (e.g., what properties are returned), error handling, and parameter semantics, leaving the agent with insufficient context to use the tool effectively beyond basic inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 but adds no parameter details. It doesn't explain what 'side_a', 'side_b', and 'side_c' represent (e.g., triangle sides in any order), units, constraints (e.g., positive numbers, triangle inequality), or examples. This fails to address the undocumented parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据三边长计算三角形的面积、周长等属性' (calculate triangle properties like area and perimeter from three side lengths). It specifies the verb ('计算' - calculate) and resource ('三角形' - triangle), though it doesn't explicitly differentiate from sibling tools like 'circle_calculation' or 'rectangle_calculation' beyond the triangle focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., valid triangle inequality), exclusions, or comparisons to other geometry tools in the sibling list. Usage is implied only by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the conversion function without mentioning what units are supported, whether it handles edge cases (like negative values), what precision it provides, or what the output format looks like. For a conversion tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese sentence that directly states the tool's function. There's zero wasted text or redundancy. It's appropriately sized for a simple conversion tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversion tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what weight units are supported, provide parameter guidance, describe the return format, or address any behavioral aspects. The agent lacks critical information needed to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so all three parameters (value, from_unit, to_unit) are undocumented in the schema. The description doesn't compensate by explaining what these parameters mean, what units are acceptable, or provide any examples. The agent must guess parameter semantics from the tool name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '在不同重量单位之间进行转换' clearly states the tool's purpose: converting between weight units. It uses a specific verb ('转换' - convert) and resource ('重量单位' - weight units), making the function immediately understandable. However, it doesn't differentiate from sibling conversion tools like length_conversion or temperature_conversion beyond the weight domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of when weight conversion is appropriate versus other conversion tools, nor any prerequisites or constraints. The agent must infer usage purely from the tool name and description without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the input constraint (value ≥1), which is useful, but doesn't describe what happens if the constraint is violated (e.g., error handling), the return format (e.g., numeric output), or any performance characteristics. For a mathematical function with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that states the purpose and constraint without any fluff. It's front-loaded with the core functionality, making it easy to parse. Every word earns its place, and there's no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mathematical function with no annotations and no output schema), the description is incomplete. It lacks details on return values, error conditions, and behavioral nuances. While it covers the basic purpose and input constraint, it doesn't provide enough context for reliable tool invocation in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It adds meaning by specifying the parameter constraint (value must be ≥1), which clarifies the semantics beyond the schema's type definition. However, it doesn't explain the parameter's role (e.g., that 'value' is the number to compute acosh for) or provide examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算反双曲余弦值' (compute inverse hyperbolic cosine). It specifies the verb (compute) and resource (inverse hyperbolic cosine), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'cosh' (hyperbolic cosine) or 'acos' (inverse cosine), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a constraint ('输入值必须≥1' - input value must be ≥1), which gives some usage context. However, it doesn't explain when to use this tool versus alternatives like 'cosh' or 'acos', nor does it mention any prerequisites or exclusions beyond the numeric constraint. This leaves gaps in guiding the agent on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the mathematical operation. It doesn't disclose behavioral traits like domain restrictions (e.g., input range), precision, error handling, or output format. For a mathematical function with no annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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. It's appropriately sized for a simple mathematical function with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical function with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address domain/range, precision, error conditions, or output format, which are important for proper usage in a computational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description implies the parameter is a numeric value for the inverse hyperbolic sine calculation. However, it doesn't add meaningful semantics beyond what the schema's type='number' already indicates. The baseline is 3 since the single parameter is straightforward, but no additional context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算反双曲正弦值' (calculates the inverse hyperbolic sine value) clearly states the mathematical operation and resource (value). It distinguishes from siblings like 'sinh' (hyperbolic sine) and 'asin' (arcsine), but doesn't explicitly contrast with 'acosh' or 'atanh' which are similar inverse hyperbolic functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention mathematical context, domain restrictions, or comparison with related functions like 'acosh' or 'atanh' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the output is in radians, which is useful context, but fails to describe other key behaviors: it does not specify the range of output (e.g., typically -π to π), handling of edge cases like (0,0), or error conditions. For a mathematical function with no annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single, clear sentence in Chinese. It efficiently conveys the core purpose without any wasted words, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mathematical function with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It covers the basic purpose and output unit but misses critical details: behavioral traits (e.g., output range, error handling), parameter semantics, and usage context. For a tool in a server with many siblings, this leaves the agent poorly equipped to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema. It clarifies that parameters represent coordinates (x, y) for angle calculation, but with 0% schema description coverage and 2 parameters, it does not compensate fully. It lacks details on parameter roles (e.g., y is numerator, x is denominator in atan2(y,x)) or units. Since schema coverage is low, the description provides some value but is insufficient for complete parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算从x轴到点(x,y)的角度（返回弧度）' which translates to 'calculate the angle from the x-axis to the point (x, y) (returns radians).' It specifies the verb (calculate), resource (angle), and output unit (radians). However, it does not explicitly differentiate from sibling tools like 'atan' or 'complex_argument,' which might have overlapping trigonometric or angular functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 lacks context on scenarios where atan2 is preferred over other trigonometric functions (e.g., for handling quadrant-specific angles or avoiding division by zero). No exclusions or prerequisites are mentioned, leaving usage unclear relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states what the tool does but lacks behavioral details: it doesn't disclose performance characteristics (e.g., time complexity for large n), error handling (e.g., for invalid inputs beyond the schema's integer range), or output format (e.g., integer result, potential overflow).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. It is front-loaded with no unnecessary words, making it highly concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mathematical computation with one parameter) and lack of annotations and output schema, the description is incomplete. It doesn't address key contextual aspects like computational limits, result interpretation, or error cases, which are important for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics: '第n个' implies 'n' is an index for the Bell number sequence. However, with 0% schema description coverage and no output schema, it doesn't explain valid ranges (e.g., non-negative integers typical for Bell numbers) or the meaning of the result. The baseline is 3 since the schema covers the parameter type and constraints, but the description doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算第n个贝尔数（集合划分数）' translates to 'calculate the nth Bell number (number of set partitions)'. This specifies the verb ('calculate') and resource ('nth Bell number'), though it doesn't explicitly differentiate from siblings like 'catalan' or 'fibonacci' beyond naming a different mathematical sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, limitations (e.g., computational constraints for large n), or suggest other tools for related tasks (e.g., 'combination' for combinatorial calculations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool calculates but doesn't mention behavioral aspects like error handling, precision, units of measurement, or what specific properties beyond area and circumference are included. For a mathematical tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese sentence that directly states the tool's function. There's no wasted verbiage or unnecessary elaboration. However, the brevity comes at the cost of completeness, as noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, no output schema, and low schema description coverage, the description is insufficiently complete. For a mathematical calculation tool that likely returns specific values, the description should at minimum clarify what properties are calculated, what units are used, and what the output format looks like. The current description leaves too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with only one parameter 'radius' documented as a number. The description doesn't add any parameter-specific information beyond implying that radius is needed for circle calculations. Since schema coverage is low, the description should compensate more by explaining parameter meaning or constraints, but it only provides minimal context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: calculating circle properties like area and circumference. It uses specific verbs ('计算' meaning 'calculate') and identifies the resource ('圆的面积、周长等属性' meaning 'circle's area, circumference, and other properties'). However, it doesn't explicitly differentiate from sibling tools like 'ellipse_calculation' or 'sphere_calculation', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of when this tool is appropriate, what prerequisites might be needed, or how it differs from similar mathematical calculation tools in the sibling list. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the calculation and unit (radians) but lacks details on edge cases (e.g., handling of zero or negative real/imaginary parts), error conditions, output format, or performance considerations. For a mathematical tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mathematical function with no annotations and no output schema, the description is incomplete. It doesn't explain the return value (e.g., a number in radians, possibly with range like -π to π), error handling, or how it interacts with sibling tools. For a tool with 2 parameters and no structured support, more context is needed to ensure reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, documenting only the parameter names and types (real and imag as numbers). The description doesn't add any parameter-specific information beyond implying they represent the real and imaginary parts of a complex number. Since the schema coverage is low, the description partially compensates by clarifying the overall purpose, but it doesn't detail parameter semantics, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算复数的幅角（以弧度为单位）' translates to 'Calculate the argument (phase angle) of a complex number in radians.' This specifies the verb (calculate), resource (complex number argument), and unit (radians). However, it doesn't explicitly distinguish this from sibling tools like 'complex_magnitude' or 'complex_polar', which might handle related complex number operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'complex_polar' (which might return polar coordinates including the argument) or 'atan2' (which could compute angles in other contexts), nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the conversion action but lacks details on output format (e.g., whether r and θ are returned as separate values or in a string), error handling (e.g., for invalid inputs), or computational behavior (e.g., precision, units for θ). This is a significant gap for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it efficient and easy to parse. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of mathematical conversion, lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address output details, error cases, or usage context, leaving gaps that could hinder an AI agent's ability to invoke the tool correctly. For a tool with these characteristics, more information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description doesn't add any parameter semantics beyond the schema's property names (real, imag). It doesn't explain what these parameters represent (e.g., real and imaginary parts of a complex number) or their expected formats. With low schema coverage, the description fails to compensate adequately, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting complex numbers to polar form (r∠θ). It specifies the verb 'convert' and the resource 'complex numbers', making it understandable. However, it doesn't explicitly differentiate from sibling tools like complex_magnitude or complex_argument, which might handle related calculations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like complex_magnitude (which might compute only the magnitude) or complex_argument (which might compute only the angle), nor does it specify any prerequisites or context for usage. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the mathematical operation without disclosing behavioral traits like input constraints (e.g., angle units, domain restrictions for undefined values like multiples of π), error handling, or output format. This is inadequate for a tool with potential mathematical edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence in Chinese) and front-loaded with the core purpose. There's no wasted text, making it efficient for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple but potentially tricky mathematical function (cotangent has undefined points), the description is incomplete. It lacks crucial context like angle units, handling of invalid inputs, and output details, which are necessary for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool has only one parameter ('angle'). The description doesn't add any parameter-specific semantics beyond implying it's an angle for cotangent calculation. It doesn't specify units (degrees/radians) or valid ranges, so it partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the mathematical function ('计算余切值' meaning 'calculate cotangent value') and provides the formula (1/tan), which is specific and unambiguous. However, it doesn't distinguish this tool from its sibling 'tan' or other trigonometric functions, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'tan' or 'csc', nor does it mention any mathematical context or prerequisites. It simply states what the tool does without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the mathematical operation without disclosing behavioral traits like error handling (e.g., for sin(angle)=0), output format, or computational constraints. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's purpose. It is front-loaded with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks information on parameter details, behavioral traits, and output format, which are critical for a mathematical function tool. The conciseness comes at the expense of necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'angle' parameter's semantics (e.g., units in radians/degrees, valid range). It only mentions the mathematical relationship 1/sin, which partially relates to the parameter but lacks essential details. Baseline would be lower due to poor coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算余割值（1/sin）' clearly states the specific mathematical operation (calculating cosecant) and the exact formula (1/sin), distinguishing it from sibling trigonometric functions like sin, cos, tan, cot, and sec. It provides precise verb+resource information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like sin or cot, nor any context about input requirements (e.g., angle units). The description only states what it does, not when or why to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the conversion action but doesn't mention potential errors (e.g., invalid inputs like non-numeric values), output format, or performance characteristics. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 without any wasted words. It is appropriately sized for a simple conversion tool and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mathematical tool with no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on error handling, return values, and usage context, making it inadequate for an agent to reliably invoke the tool without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description implies the parameter 'degrees' is a numeric angle value. However, it doesn't specify units, valid ranges (e.g., negative values allowed?), or conversion formula details. The description adds minimal semantic value beyond the parameter name, insufficient to fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '将角度转换为弧度' (convert degrees to radians) clearly states the tool's function with a specific verb and resource. It distinguishes from sibling tools like 'radToDeg' by specifying the direction of conversion, though it doesn't explicitly contrast with all mathematical functions in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'radToDeg' or other conversion tools. It lacks any context about prerequisites, typical use cases, or comparisons with sibling tools, leaving the agent to infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does (division) without mentioning critical behaviors like error handling (e.g., division by zero), input constraints (e.g., numeric types only), or output format. This leaves significant gaps for an AI agent to understand how to use it safely and effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: '执行两个数字的除法运算'. It's front-loaded with the core action and resource, with zero wasted words, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (basic arithmetic), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on error cases (e.g., division by zero), output format, or behavioral traits, which are essential for an AI agent to invoke it correctly in various scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It implies two parameters ('两个数字' - two numbers) but doesn't name them (a, b) or explain their roles (e.g., dividend and divisor). This adds minimal semantics beyond the schema, resulting in a baseline score of 3 due to the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '执行两个数字的除法运算' (performs division of two numbers). It specifies the verb (division) and resource (two numbers), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'complex_divide' or 'modulo', which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'complex_divide' for complex numbers or 'modulo' for remainder operations, nor does it specify any context or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool calculates area and perimeter (approximate), but does not disclose behavioral traits such as the mathematical formulas used, precision of approximations, error handling for invalid inputs (e.g., negative axes), or output format. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '计算椭圆的面积和周长（近似）'. It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a straightforward calculation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on behavior, parameter meanings, output format, and usage context. For a mathematical tool with two parameters, this minimal description does not provide enough information for an agent to use it effectively beyond basic inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 implies parameters for ellipse dimensions but does not name or explain 'semi_major_axis' and 'semi_minor_axis' from the schema. The description adds minimal value beyond the schema's parameter names, resulting in a baseline score of 3 due to the simple nature of the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算椭圆的面积和周长（近似）' (calculates the area and perimeter/approximate circumference of an ellipse). It specifies the verb (calculate) and resource (ellipse), but does not differentiate from sibling tools like 'circle_calculation' or 'rectangle_calculation' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention sibling tools like 'circle_calculation' for circular calculations or 'regular_polygon' for other shapes, nor does it specify prerequisites or exclusions for ellipse-specific calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does (generates Fibonacci sequence terms) but doesn't describe any behavioral traits such as performance characteristics, error handling (e.g., for negative or large n values), output format, or computational limits. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: '生成斐波那契数列的前n项'. It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple mathematical tool. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, mathematical function), the description is incomplete. No annotations are provided to cover behavioral aspects, and there's no output schema to explain return values. The description lacks details on output format (e.g., list of integers), error conditions, or usage context, making it inadequate for full agent understanding despite the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions '前n项' (first n terms), which implies the parameter 'n' represents the number of terms to generate. However, schema description coverage is 0%, and the description doesn't add details beyond this basic implication—no information on valid ranges (beyond the schema's technical limits), default behavior, or examples. With one parameter and low schema coverage, the description provides minimal but not comprehensive semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '生成斐波那契数列的前n项' (generate the first n terms of the Fibonacci sequence). It specifies the verb ('生成' - generate) and resource ('斐波那契数列的前n项' - first n terms of Fibonacci sequence). However, it doesn't explicitly differentiate from sibling tools like 'fibonacci' (which might generate a single Fibonacci number rather than a sequence), so it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'fibonacci' (which might serve a similar purpose), nor does it specify any context or prerequisites for usage. The agent must infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the mathematical operation but fails to disclose behavioral traits such as input validation (e.g., handling of invalid angles), error conditions (e.g., division by zero when cos(angle)=0), or output format (e.g., numerical result). This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core purpose. There is no wasted text, making it efficient for quick understanding, though it may lack necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple but undocumented parameter, the description is incomplete. It covers the basic function but misses critical context like error handling, mathematical domain, and result format, which are essential for safe and correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any parameter details beyond the schema. It implies 'angle' is the input but doesn't specify units (degrees/radians) or constraints. With one parameter and no schema descriptions, the baseline is moderate as the parameter is simple, but no extra semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the mathematical function (计算正割值) and provides the formula (1/cos), which is specific and unambiguous. It distinguishes from siblings like 'cos' by indicating it's the reciprocal, though it doesn't explicitly compare to other trigonometric tools like 'csc'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'cos' or 'csc', or about mathematical constraints (e.g., angle units, domain restrictions where cos(angle) ≠ 0). The description only states what it does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the input unit (radians), which is useful context, but fails to describe key behavioral traits: it doesn't specify the output format (e.g., numeric value), error handling (e.g., for invalid inputs), or mathematical constraints (e.g., domain or precision). For a mathematical tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence that directly states the purpose and key constraint (radians input). There is no wasted language or redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description is incomplete. It covers the basic purpose and input unit but lacks details on output (e.g., numeric result), behavioral aspects (e.g., error handling), and usage relative to siblings. For a mathematical function, more context on expected behavior and alternatives would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the schema provides no parameter details. The description adds some semantics by specifying that the 'angle' parameter is in radians, which clarifies the input unit. However, it doesn't explain the parameter's name, expected range, or format beyond this, leaving gaps in understanding. With one parameter and partial compensation, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算角度的正弦值' (calculates the sine of an angle). It specifies the verb (calculate) and resource (sine value), and distinguishes it from siblings like 'cos' or 'tan' by focusing on sine. However, it doesn't explicitly differentiate from all siblings (e.g., 'sinh' for hyperbolic sine), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: it notes that the input is in radians ('输入为弧度'), which is essential context for correct use. However, it doesn't specify when to use this tool versus alternatives (e.g., 'sinh' for hyperbolic sine, 'asin' for arcsine, or 'degToRad' for conversion), nor does it mention prerequisites or exclusions. This lack of comparative guidance limits its helpfulness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions calculation but doesn't disclose behavioral traits such as error handling (e.g., for negative inputs), precision, or return format. For a mathematical function with no annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the purpose without any wasted words. It's appropriately sized and front-loaded for a simple mathematical function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description is incomplete. It lacks details on behavior (e.g., handling of edge cases), parameter semantics, and usage context, which are necessary for an AI agent to invoke it correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies a single parameter for the number, but with 0% schema description coverage and no additional details in the description (e.g., constraints like non-negative values), it adds minimal meaning beyond what the schema's type indicates. The baseline is 3 since the schema provides basic structure, but the description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算数字的平方根' (calculates the square root of a number) clearly states the verb ('计算' - calculate) and resource ('平方根' - square root). It distinguishes from siblings like 'cbrt' (cube root) and 'nthRoot' (n-th root) by specifying square root, though it doesn't explicitly mention this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'cbrt' or 'nthRoot' is provided. The description only states what it does, not when it's appropriate or any prerequisites (e.g., input must be non-negative for real results).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the operation but doesn't mention potential edge cases (e.g., floating-point precision, handling of negative results), error conditions, or what the output format will be. For a mathematical operation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for this simple mathematical operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical operation with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool returns, doesn't address edge cases or error conditions, and provides minimal guidance about usage context. The simplicity of the operation saves it from a score of 1.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions '两个数字' (two numbers) which maps to the two parameters, but doesn't specify which is minuend/subtrahend or add any semantic meaning beyond what's obvious from the tool name. This provides minimal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '执行两个数字的减法运算' (perform subtraction of two numbers) clearly states the verb (subtract) and resource (two numbers). It's specific about what the tool does, though it doesn't explicitly distinguish from sibling tools like 'complex_subtract' or 'matrix_subtract' which handle different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention that this is for simple numeric subtraction (as opposed to complex or matrix subtraction available in sibling tools), nor does it provide any context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs addition but doesn't describe error handling (e.g., for non-numeric inputs), performance characteristics, or output format. For a simple arithmetic tool, this is somewhat acceptable but lacks completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function without any fluff. It's front-loaded and wastes no words, making it highly concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple arithmetic tool with 2 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic operation but lacks details on output (e.g., returns a number), error cases, or precision, which could be helpful given the mathematical context and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies two parameters ('两个数字' - two numbers), which aligns with the schema's 'a' and 'b'. However, with 0% schema description coverage, the description doesn't add details like parameter order, data types beyond 'numbers', or examples. It compensates minimally but doesn't fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '执行两个数字的加法运算' (perform addition of two numbers), which is a specific verb+resource combination. It distinguishes from siblings like 'subtract', 'multiply', and 'divide' by specifying addition, though it doesn't explicitly mention these alternatives in the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'sum' (which might handle multiple numbers) or 'complex_add' (for complex numbers). There's no mention of prerequisites, constraints, or comparison with sibling tools, leaving usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what the tool does (calculates cosine) and the input format (radians). It lacks behavioral details such as error handling (e.g., for invalid inputs), performance characteristics, or output format. For a mathematical function with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence that directly states the tool's function and input requirement. There is no wasted text, and every word earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a basic mathematical function), no annotations, no output schema, and one parameter, the description is minimally adequate. It covers the core purpose and input unit, but lacks details on output format, error cases, or usage context. For such a simple tool, this is acceptable but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that the 'angle' parameter should be in radians, which is crucial semantic context not in the schema. However, it doesn't explain the parameter's name, range, or units beyond 'radians', leaving some ambiguity. With one parameter and partial compensation, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算角度的余弦值' (calculates the cosine of an angle). It specifies the input unit (radians) and distinguishes it from potential degree-based alternatives. However, it doesn't explicitly differentiate from sibling trigonometric functions like 'sin' or 'tan', which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mentions the input is in radians, but doesn't specify scenarios where cosine is appropriate over other trigonometric functions or mathematical operations available in the sibling list. There's no mention of prerequisites, limitations, or comparison to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool calculates volume and surface area, implying a read-only operation, but doesn't specify if it's a pure function, if it has side effects, error handling, or output format. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '计算长方体的体积和表面积'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a straightforward mathematical tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a simple geometric calculation), no annotations, no output schema, and self-explanatory parameters, the description is minimally adequate. It states what the tool does but lacks details on usage, behavior, or output format, making it incomplete for full contextual understanding without external inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters at all, and schema description coverage is 0%, so it adds no meaning beyond the input schema. However, the parameters (length, width, height) are self-explanatory for a cuboid calculation, and with 0 parameters documented in the schema, the baseline is 3 as the description doesn't need to compensate heavily for simple, intuitive parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算长方体的体积和表面积' (calculates the volume and surface area of a cuboid). It specifies the verb '计算' (calculate) and the resource '长方体' (cuboid) with the outputs '体积和表面积' (volume and surface area). However, it doesn't differentiate from sibling tools like 'rectangle_calculation' or 'sphere_calculation', which are also geometric calculators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, context, or comparisons to sibling tools such as 'rectangle_calculation' (for 2D rectangles) or 'sphere_calculation' (for spheres). The user must infer usage based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it explains what a perfect number is, it doesn't describe the tool's behavior: whether it returns a boolean, what happens with invalid inputs (e.g., negative numbers or non-integers given the schema allows negative integers), performance characteristics, or error handling. The description adds minimal behavioral context beyond the basic mathematical definition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: a single sentence that directly states the tool's purpose with zero wasted words. Every element ('判断', '正整数', '完全数', '真因子之和') earns its place by contributing essential information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical nature, no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain the return type (presumably boolean but unspecified), doesn't address input validation issues (schema allows negatives but description says positive integers), and provides no context about performance or limitations for large numbers. For a tool with one parameter but poor schema documentation, the description should do more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for undocumented parameters. The description mentions '正整数' (positive integer) which adds semantic meaning beyond the schema's generic integer type with wide range (-2147483648 to 2147483647). However, it doesn't fully explain the parameter's purpose or constraints (e.g., that n should be positive despite the schema allowing negatives), leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '判断一个正整数是否为完全数（等于其所有真因子之和）' which translates to 'determines whether a positive integer is a perfect number (equal to the sum of all its proper divisors)'. It specifies the verb ('判断' - determine), resource ('正整数' - positive integer), and distinguishes it from siblings by focusing on perfect number checking, unlike other mathematical functions like isPrime or divisorCount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like isPrime, divisorCount, or divisorList that might be relevant for related number theory tasks. There's no context about when perfect number checking is appropriate compared to other mathematical operations available on the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the mathematical operation but doesn't disclose behavioral traits: it doesn't mention error handling (e.g., for non-positive inputs), numerical precision, or return format. For a mathematical tool with no annotations, this leaves significant gaps in understanding how it behaves in edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 function. It's front-loaded with no unnecessary words, making it easy to parse quickly. Every part of the sentence earns its place by defining the mathematical operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single mathematical function) and lack of annotations/output schema, the description is minimally complete. It states what the tool does but misses details like error conditions or return values. For a simple tool among many mathematical siblings, this is adequate but leaves room for improvement in guiding usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It implies the parameter 'value' is the number to take the logarithm of, but doesn't specify constraints (e.g., must be positive), units, or examples. This adds minimal meaning beyond the schema's type definition, meeting the baseline for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算以10为底的对数' clearly states the tool's purpose: it computes the base-10 logarithm of a given value. This is a specific mathematical operation that distinguishes it from sibling tools like 'ln' (natural logarithm) or 'log' (which might be ambiguous). However, it doesn't explicitly mention the input parameter 'value' or contrast with other logarithmic functions beyond the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'ln' for natural logarithms or 'log' (which might be base-10 or another base), nor does it specify use cases (e.g., scientific calculations, decibel scaling). The agent must infer usage from the mathematical function alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states what the tool does but doesn't describe how it handles edge cases (e.g., multiple modes, empty arrays, non-numeric elements), what format the output takes, or whether it modifies input data. For a statistical tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple mathematical function and front-loads the essential information. Every word earns its place in conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a statistical calculation tool with no annotations, no output schema, and 0% parameter documentation, the description is incomplete. It doesn't address output format, error handling, mathematical assumptions, or common usage patterns. While concise, it lacks the contextual information needed for reliable tool invocation in various scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for undocumented parameters. It mentions '数组' (array) which maps to the 'numbers' parameter, but doesn't specify expected element types (numbers only? mixed types?), array size constraints, or handling of invalid inputs. With 1 parameter at 0% coverage, the description adds minimal semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific mathematical operation ('计算数组的众数') with the exact resource ('数组'), distinguishing it from sibling tools like 'mean', 'median', 'max', and 'min' that perform different statistical calculations. It uses precise terminology that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'mean', 'median', 'max', or 'min'. It doesn't mention typical use cases for mode calculation (e.g., finding most frequent values in datasets) or any prerequisites. The agent must infer usage from the mathematical definition alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While '计算' (calculate) implies a read-only computation, the description doesn't specify whether this requires any special permissions, what units are used (e.g., radius input units vs. output units), whether negative radii are handled, or what happens with invalid inputs. For a mathematical computation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states what the tool does. There's zero wasted language, and the information is front-loaded with no unnecessary elaboration. For a simple mathematical tool, this level of conciseness is appropriate and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, mathematical computation), the description is minimally adequate. However, with no annotations, no output schema, and 0% schema description coverage, there are gaps in understanding the tool's behavior, error handling, and output format. The description covers the basic purpose but leaves other contextual aspects unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters at all, and schema description coverage is 0%. However, there's only one parameter (radius), and the tool's purpose inherently implies that radius is the input needed for sphere calculations. The description doesn't add specific meaning beyond what can be inferred from the tool name and purpose, but with just one parameter, the baseline is reasonable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算球体的体积和表面积' (calculates the volume and surface area of a sphere). It specifies both outputs (volume and surface area) and the resource (sphere), making the verb+resource combination clear. However, it doesn't explicitly differentiate from sibling tools like 'circle_calculation' or 'cone_calculation' which might have overlapping geometric calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are many sibling tools for geometric calculations (circle_calculation, cone_calculation, cuboid_calculation, etc.), but the description doesn't indicate this is specifically for spheres or when to choose it over other shape calculation tools. No context about prerequisites or exclusions is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the input must be in radians, which is useful context, but doesn't mention other behavioral traits such as error handling (e.g., for undefined values like π/2), output format, or performance considerations. For a mathematical function tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: '计算角度的正切值（输入为弧度）' is a single, efficient sentence that directly states the tool's function and key input constraint. There is no wasted verbiage or redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a simple mathematical function), no annotations, no output schema, and minimal parameters, the description is somewhat complete but has gaps. It covers the basic purpose and input unit, but lacks details on usage guidelines, behavioral transparency, and output semantics. For such a straightforward tool, this might be minimally adequate, but improvements could enhance agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic information. The description adds value by specifying that the parameter 'angle' must be in radians, which clarifies the unit requirement. However, it doesn't explain the parameter's name, range, or any constraints beyond the unit, leaving some ambiguity. Given the low schema coverage, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算角度的正切值（输入为弧度）' translates to 'Calculate the tangent of an angle (input in radians)'. This specifies the verb ('calculate'), resource ('tangent of an angle'), and input constraint ('radians'), making the purpose clear. However, it doesn't explicitly distinguish this tool from sibling trigonometric functions like 'sin' or 'cos', which have similar patterns but compute different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mentions the input must be in radians, but doesn't specify use cases, prerequisites, or comparisons to other tools like 'tanh' (hyperbolic tangent) or 'atan' (inverse tangent). Without such context, an agent might struggle to select this tool appropriately in complex scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what the tool does (multiplication) without any behavioral context about error handling, numerical precision, overflow behavior, or return format. For a mathematical operation with no annotation coverage, this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's perfectly front-loaded with the essential information and earns its place completely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mathematical operation with 2 parameters and no output schema, the description provides basic functionality but lacks important context. No annotations exist to cover behavioral aspects, and the description doesn't address numerical constraints, error cases, or result format, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (parameters 'a' and 'b' have no descriptions in schema), the description compensates by clearly indicating these are '两个数字' (two numbers). While it doesn't specify parameter order or naming, it establishes the essential semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('执行乘法运算' - perform multiplication) and resource ('两个数字' - two numbers), making the purpose immediately understandable. It distinguishes from siblings like 'add' or 'divide' by specifying multiplication, though it doesn't explicitly contrast with similar mathematical operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling mathematical tools (add, divide, power, etc.), there's no indication of when multiplication is appropriate versus other operations or when to choose this over similar tools like 'product' which might handle multiple numbers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '计算' (calculate) implies a read-only computation, the description doesn't disclose important behavioral traits: it doesn't mention what happens with invalid inputs (like negative n, though Catalan numbers are typically defined for non-negative integers), potential performance characteristics, error conditions, or the format/type of the return value. For a mathematical computation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple mathematical function and front-loads the core purpose immediately. Every word earns its place in conveying the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mathematical computation tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what Catalan numbers are for users unfamiliar with them, doesn't specify valid input ranges, doesn't describe the return type or format, and doesn't mention any mathematical properties or constraints. For a tool that could have domain-specific requirements, this leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The description mentions '第n个' (the nth) which provides semantic context for the parameter n, indicating it's an index/position. However, it doesn't specify valid ranges (Catalan numbers are typically defined for n ≥ 0), doesn't explain what n represents mathematically, and doesn't mention constraints like integer requirements or typical usage bounds. With 1 parameter and 0% schema coverage, the description adds minimal value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算第n个卡塔兰数' (calculate the nth Catalan number) clearly states the specific mathematical operation being performed. It uses a precise verb ('计算' - calculate) and identifies the exact resource (Catalan number), distinguishing it from all sibling tools which perform different mathematical functions like factorial, fibonacci, or trigonometric operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the mathematical term '卡塔兰数' (Catalan number), suggesting this tool should be used when Catalan numbers are needed. However, it provides no explicit guidance on when to use this versus alternatives, nor does it mention any prerequisites or constraints beyond the parameter n. The mathematical context is clear but not explicitly stated as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool calculates but doesn't disclose important behavioral aspects: no information about input validation (e.g., what happens if r > n or if values are negative), no mention of computational limits or performance characteristics, and no description of error handling. The description is purely functional without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 with zero wasted words. It's appropriately sized for this simple mathematical function and front-loads the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It explains what the tool calculates but doesn't cover: input constraints, error conditions, return format, mathematical domain restrictions, or performance considerations. For a mathematical tool with two parameters, more contextual information would be helpful for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds meaningful semantics by explaining that 'n' represents total elements and 'r' represents selected elements for the combination calculation. However, it doesn't specify constraints (e.g., r ≤ n, non-negative integers) or provide examples of valid values, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific mathematical operation: '计算从n个元素中选择r个元素的组合数 C(n,r)' which translates to 'calculate the number of combinations C(n,r) of selecting r elements from n elements'. It uses precise mathematical terminology and distinguishes itself from sibling tools like 'permutation' by specifying it's about combinations rather than permutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for combinatorial calculations but doesn't explicitly state when to use this tool versus alternatives. While the mathematical context is clear, there's no guidance about when to choose this over other mathematical tools or what specific scenarios warrant its use. The sibling tool list includes 'permutation' which is closely related, but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While it explains what the function computes, it doesn't disclose behavioral traits such as input validation (e.g., handling of non-positive integers, large values), performance characteristics, error handling, or output format. For a mathematical tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mathematical function with no annotations, no output schema, and low parameter documentation, the description is incomplete. It lacks information on output format, error conditions, performance, and practical usage examples, which are important for an AI agent to invoke the tool correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by explaining that 'n' is the input for Euler's totient function. However, it doesn't provide details beyond the basic definition, such as valid ranges (though the schema specifies -2147483648 to 2147483647) or handling of edge cases. With one parameter and low schema coverage, the description compensates partially but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific mathematical function (Euler's totient function φ(n)) and defines it precisely as 'the number of positive integers less than or equal to n that are coprime to n.' It uses a specific verb ('计算' meaning 'calculate') with the resource (φ(n)), and distinguishes itself from sibling tools by focusing on this unique number theory function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for computing Euler's totient function, which is sufficient given the mathematical context and sibling tools being distinct mathematical operations. However, it doesn't provide explicit guidance on when to use this versus alternatives (e.g., for primality testing or other number theory functions), nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '计算' (calculate) implies a read-only mathematical operation, the description doesn't disclose any behavioral traits like error conditions (e.g., handling of non-numeric inputs), performance characteristics, or what happens with special values (infinity, NaN). It's a minimal functional statement without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 or unnecessary elaboration. It's appropriately sized for a simple mathematical function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mathematical function with 2 parameters and no annotations, the description is minimally complete. It states what the tool does but lacks behavioral details (error handling, special cases) and usage guidance. Without an output schema, it doesn't describe the return value format. The description meets basic requirements but leaves gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (no parameter descriptions in schema), the description doesn't explicitly mention parameters. However, for a mathematical function with exactly 2 parameters (real and imag), the tool name and description strongly imply the parameters represent the real and imaginary parts of a complex number. This is adequate semantic context for such a standard operation, though not explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算复数的模长（绝对值）' (Calculate the magnitude/absolute value of a complex number) clearly states the specific verb ('计算' - calculate) and resource ('复数的模长' - magnitude of complex number). It distinguishes from sibling tools like 'abs' (which might be for real numbers) and 'complex_argument' (which calculates the argument/phase).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 to use 'complex_magnitude' instead of 'abs' (which might handle both real and complex numbers) or other mathematical operations. No context about prerequisites or typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool calculates but doesn't disclose behavioral traits like input validation (e.g., whether r ≤ n is required), error handling, output format, or computational limitations. The description is purely functional without operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's front-loaded with the core functionality and uses standard mathematical notation for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical calculation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks information about parameter constraints, return value format, error conditions, and mathematical assumptions (e.g., integer inputs, r ≤ n requirement). The description alone doesn't provide enough context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains that n represents 'n个元素' (n elements) and r represents '选择r个元素' (selecting r elements), adding semantic meaning beyond the schema's type constraints. However, it doesn't specify parameter constraints (e.g., r ≤ n, non-negative integers) or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific mathematical operation: '计算从n个元素中选择r个元素的排列数 P(n,r)' (calculates the number of permutations P(n,r) of selecting r elements from n elements). It uses precise mathematical terminology (排列数, P(n,r)) and distinguishes itself from sibling tools like 'combination' which calculates combinations rather than permutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (for permutation calculations) versus alternatives like 'combination' for combination calculations, but doesn't explicitly name alternatives or provide exclusion criteria. The mathematical context is clear, but no explicit guidance on when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While it states what the tool does (calculates natural logarithm), it provides no information about error handling (e.g., what happens with negative or zero inputs), precision, return format, or computational characteristics. For a mathematical function with no annotation coverage, this represents significant gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese phrase that communicates the essential purpose without any wasted words. It's perfectly front-loaded with the core functionality and uses mathematical terminology that's standard and unambiguous in this context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical function with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. While it clearly states the mathematical operation, it lacks crucial context about parameter constraints (positive numbers only), error conditions, return format, and precision. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about the single 'value' parameter. It doesn't explain what the parameter represents (the number to take the natural logarithm of), valid ranges (must be positive), or units. With low schema coverage and no parameter details in the description, this fails to compensate for the documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '计算自然对数（以e为底）' (calculates natural logarithm with base e) clearly states the specific mathematical operation (natural logarithm) and distinguishes it from sibling tools like 'log' (generic logarithm) and 'log10' (base-10 logarithm). It uses precise terminology that identifies both the verb (calculate) and resource (natural logarithm).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly provides excellent usage guidance by specifying '以e为底' (with base e), which clearly differentiates it from the 'log' and 'log10' sibling tools. This tells the agent exactly when to use this tool (for natural logarithms) versus alternatives (for other bases). The mathematical context makes the distinction self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 helpfully adds the critical constraint that '输入值必须在-1到1之间' (input value must be between -1 and 1), which is essential behavioral information not in the schema. However, it doesn't describe error handling for invalid inputs or the mathematical precision/format of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that states the operation and the critical constraint. Every word earns its place with zero waste. The most important information (the mathematical function) comes first, followed by the constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mathematical function with no annotations and no output schema, the description provides the essential operation and input constraint. However, it doesn't describe the output format (e.g., returns a number, precision, units) or error behavior for invalid inputs, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clearly explains that the single parameter is the input value for the mathematical function and specifies the valid range (-1 to 1). This adds meaningful semantic context beyond the bare schema, though it doesn't explain the data type or units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific mathematical function ('计算反双曲正切值' - compute inverse hyperbolic tangent) and identifies the single input parameter ('输入值' - input value). It distinguishes from siblings like tanh (hyperbolic tangent) and atan (arc tangent) by specifying the inverse hyperbolic operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool by specifying the mathematical operation. However, it doesn't explicitly mention when not to use it or name alternative tools for related operations (e.g., using tanh for forward hyperbolic tangent or atan for arc tangent).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![1777316659204099 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659204099/badges/card.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659204099)

Score Badge

Copy to your README.md:

[![1777316659204099 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659204099/badges/score.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659204099)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xiaobenyang-com/1777316659204099'

If you have feedback or need assistance with the MCP directory API, please join our Discord server