Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Math MCP Server calculate the integral of x^2 from 0 to 5"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Python-based mathematical computation MCP server, providing a suite of mathematical computation tools and plotting utilities.
uvx math-mcp # using uvx
# Or run the .py file directly (dependencies must be installed manually)
python math_mcp/math_mcp_server.pymath_mcp/
├── __init__.py # Package initialization
├── __main__.py # CLI entry point
├── math_mcp_server.py # Main server file (MCP tool registration)
├── file_utils.py # File path utilities
# Core computation modules
├── basic.py # Basic math computation
├── matrix.py # Matrix computations
├── mstatistics.py # Statistical analysis (avoid conflicts)
├── calculus.py # Calculus
├── optimization.py # Optimization algorithms
├── regression.py # Regression analysis
├── plotting.py # Data visualization
├── geometry.py # Geometric computations
├── number_theory.py # Number theory
├── complex_analysis.py # Complex analysis
├── probability.py # Probability and statistics
# Extended specialized modules
├── signal_processing.py # Signal processing
├── financial.py # Financial mathematics
└── graph_theory.py # Graph theory analysisAdd the following configuration to your Claude Desktop config file:
{
"mcpServers": {
"math-calculator": {
"command": "uvx",
"args": ["math-mcp"],
"env": {
"OUTPUT_PATH": "path/to/output",
"FONT_PATH": "path/to/font"
}
}
}
}Or start the server directly:
{
"mcpServers": {
"math-calculator-local": {
"command": "path/to/python_interpreter",
"args": [
"path/to/math_mcp_server.py"
],
"env": {
"OUTPUT_PATH": "path/to/output",
"FONT_PATH": "path/to/font"
}
}
}
}Brief description: Basic arithmetic operations tool, supporting addition, subtraction, multiplication, division, and high-precision calculations. //
Examples:
basic_arithmetic(operation='add', numbers=[1, 2, 3, 4, 5])
basic_arithmetic(operation='multiply', numbers=[2.5, 3.7], precision=3)
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Arithmetic operation type. Supports: 'add', 'subtract', 'multiply', 'product', 'divide', 'power', 'modulo', 'modulus', 'factorial', 'gcd', 'lcm', 'sum', 'average' | |
| numbers | Yes | List of numbers for the operation. Must contain at least one number | |
| precision | No | Number of decimal places for the result. Range 0-15 | |
| use_decimal | No | Whether to use high-precision decimal calculation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It mentions 'high-precision calculations' (via use_decimal) but fails to disclose error handling, return format, or edge cases (e.g., division by zero). Vital behavioral traits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only a brief sentence and two examples. It is front-loaded and contains no filler. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple arithmetic tool with no output schema, the description is adequate but minimal. It lacks information about return value type, error behavior, or complex operation details. Given the tool's straightforward nature, a score of 3 reflects the bare minimum completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with property descriptions. The description adds value through concrete examples showing correct parameter usage (e.g., numbers list, precision argument). This helps an agent understand formatting beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'basic arithmetic operations' and provides specific examples ('add', 'multiply'). However, it does not differentiate this tool from siblings like 'expression_evaluator' or 'precision_calculator', nor does it explicitly state the scope (only basic operations). A score of 4 is appropriate for clarity without sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or when not to use it. The examples imply straightforward use cases, but no explicit comparison to sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Advanced calculus computation engine, supporting derivatives, integrals, limits, series, and differential equations.
Examples:
calculus_engine(expression='x**2 + 3*x + 1', operation='derivative', variable='x')
calculus_engine(expression='sin(x)', operation='integral', variable='x', limits=[0, 3.14159])
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | Mathematical expression to analyze | |
| operation | Yes | Calculus operation type. Supports: 'derivative', 'integral', 'limit', 'series', 'differential_equation', 'optimization', 'taylor_series', 'fourier_series' | |
| variable | No | Variable symbol | x |
| variables | No | List of variables for multivariate functions | |
| limits | No | Integration limits or limit calculation bounds | |
| point | No | Point for derivative or limit evaluation | |
| points | No | Multiple points for evaluation | |
| order | No | Order of derivative or series terms | |
| method | No | Calculation method. Supports: 'quad', 'dblquad', 'symbolic', 'numerical' | quad |
| mode | No | Calculation mode. Supports: 'symbolic', 'numerical' | symbolic |
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 does not mention side effects (none expected), authentication needs, rate limits, or error behavior. The description only offers a high-level definition and examples, which is insufficient for a tool with 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief—two sentences and two examples—which is concise and front-loaded. However, it could be better structured by separating the brief description from examples, and by including a bullet list of operations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description covers only the basics. The examples address only a few operations and parameter combinations. Missing key details like how to specify methods, modes, or handle errors, but it provides enough to start using the tool for common cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed parameter descriptions. The description adds value by showing example parameter combinations (expression, operation, variable, limits) that clarify typical usage. However, it does not explain more complex parameters like method or mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an advanced calculus computation engine supporting derivatives, integrals, limits, series, and differential equations. Examples further illustrate typical use cases. However, it does not explicitly differentiate from sibling tools like complex_analysis_suite or optimization_suite, relying on the listed operations to imply scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples demonstrate basic usage but there is no explicit guidance on when to use this tool versus alternatives (e.g., when to use complex_analysis_suite instead). No prerequisites or contraindications are mentioned, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Deletes files generated in OUTPUT_PATH (or default temporary directory) and performs basic resource cleanup. Call only when the user explicitly indicates deletion of temporary or output files.
Examples:
cleanup_resources()
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states what is deleted and performs 'basic resource cleanup,' but lacks specifics on fallback behavior if OUTPUT_PATH is unset, whether subdirectories are affected, or potential side effects. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence and a usage example. Every word is necessary, with no redundancy. It is front-loaded and efficiently communicates the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is complete. It specifies the action, resources, usage condition, and provides an example. No additional information is needed for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description carries the full semantic burden. The description explains the tool's purpose and operation, adding meaningful context beyond the empty schema. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('deletes files') and the resources involved ('OUTPUT_PATH or default temporary directory'). It distinguishes itself from the sibling tools, which are all math/calculation tools, making its purpose specific and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call only when the user explicitly indicates deletion of temporary or output files.' This instructs the agent on appropriate invocation context. No need for alternatives since siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description:
Powerful complex analysis and complex function tool, supporting complex number form conversion, residue calculation, analytic continuation, complex plane visualization, and other advanced features.
Examples:
complex_analysis_suite(operation='convert_form', complex_number='3+4i')
complex_analysis_suite(operation='function_evaluation', function_expression='z**2 + 1', complex_number='1+i')
complex_analysis_suite(operation='residue_calculation', function_expression='1/(z**2 + 1)', singularities=['i', '-i'])
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Complex analysis operation. Supports: 'arithmetic', 'complex_functions', 'contour_integration', 'residue_calculation', 'series_expansion', 'visualization' | |
| complex_number | No | Single complex number (string or complex type) | |
| complex_numbers | No | List of complex numbers for operations | |
| function_expression | No | Complex function expression | |
| variable | No | Complex variable symbol | z |
| contour_points | No | Contour points for integration | |
| singularities | No | List of function singularities | |
| center | No | Center point for expansion | |
| radius | No | Radius for convergence | |
| order | No | Order of expansion or pole | |
| x_range | No | Real axis range for visualization | |
| y_range | No | Imaginary axis range for visualization | |
| resolution | No | Plot resolution | |
| colormap | No | Colormap for visualization | hsv |
| filename | No | Output filename for plots | |
| plot_type | No | Visualization type. Supports: 'domain_coloring', 'contour_plot', 'surface_plot' | domain_coloring |
| series_terms | No | Number of series terms | |
| branch_cut | No | Branch cut specification | |
| method | No | Calculation method | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only gives a high-level feature list without mentioning side effects, performance implications, or error handling. The tool could modify resources or have destructive behaviors, but nothing is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with only 3 sentences and three examples. It front-loads key features and uses a structure that is easy to scan. The first sentence could be more precise, but overall it is concise for a tool with 19 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (19 parameters, no output schema, no annotations), the description is incomplete. It does not explain return values, covers only a subset of operations in examples, and fails to address how parameters interact or what happens with invalid inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds three examples that illustrate parameter combinations, which provides some extra context. However, it does not clarify parameter relationships or constraints beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a complex analysis suite, mentioning specific features like form conversion and residue calculation. However, there is a mismatch between the described features (e.g., 'analytic continuation') and the actual operation categories listed in the schema, making the purpose slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus its siblings (e.g., basic_arithmetic, plot_function_curve). It does not state prerequisites or situations where alternative tools are more appropriate, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Data visualization and chart creation tool, supporting various statistical chart types.
Examples:
create_and_save_chart(chart_type='line', x_data=[1,2,3,4], y_data=[1,4,2,3], title='Line Plot')
create_and_save_chart(chart_type='histogram', data=[1,2,2,3,3,3,4,4,5], filename='histogram_plot')
| Name | Required | Description | Default |
|---|---|---|---|
| chart_type | Yes | Chart type. Supports: 'bar', 'pie', 'line', 'scatter', 'histogram', 'box', 'heatmap', 'correlation_matrix', 'multi_series_line' | |
| data | No | Single series data for bar, pie, histogram, box plots | |
| x_data | No | X-axis data for line, scatter, multi-series line plots | |
| y_data | No | Y-axis data for line, scatter plots | |
| y_data_series | No | Multi-series Y-axis data for multi-series line plots | |
| series_labels | No | Labels for multi-series plots | |
| matrix_data | No | Matrix data for heatmaps, correlation matrices | |
| labels | No | Data labels for bar charts, pie charts | |
| title | No | Chart title | Statistical Chart |
| xlabel | No | X-axis label | X Axis |
| ylabel | No | Y-axis label | Y Axis |
| filename | No | Save filename without path and extension | |
| format | No | Image format. Supports: 'png', 'jpg', 'svg' | png |
| colors | No | List of custom colors for chart elements | |
| figsize | No | Figure size as (width, height) | |
| dpi | No | Image resolution | |
| style | No | Chart style | whitegrid |
| timestamp | No | Whether to add timestamp to filename | |
| show_values | No | Whether to display value labels on bar charts | |
| horizontal | No | Whether to create horizontal bar chart | |
| trend_line | No | Whether to display trend line on scatter plots | |
| trend_line_color | No | Trend line color | |
| trend_line_equation | No | Trend line equation text | |
| bins | No | Number of bins for histogram | |
| annotate | No | Whether to display numerical annotations on heatmaps | |
| colormap | No | Colormap for heatmaps | viridis |
| color | No | Single color | |
| line_width | No | Line width for line plots | |
| line_style | No | Line style | - |
| marker | No | Marker style | o |
| marker_size | No | Marker size | |
| alpha | No | Transparency level | |
| grid | No | Whether to display grid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not mention side effects, permissions, or that the tool saves charts to files. The filename parameter implies saving, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with a brief line and examples, making it concise. However, it lacks sections or structure, which could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 33 parameters and no output schema, the description is too minimal. It fails to explain save behavior, return values, or how parameters interact for different chart types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds examples but does not explain parameter combinations or chart type specifics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a data visualization and chart creation tool with examples. However, it does not differentiate from sibling tools like 'plot_function_curve', which may also produce plots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only provides examples 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.
Brief description: Mathematical expression evaluation and symbolic computation tool.
Examples:
expression_evaluator(expression='2*x + 3*y', variables={'x': 5, 'y': 7})
expression_evaluator(expression='x**2 + 2*x + 1', mode='factor')
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | Mathematical expression to evaluate | |
| variables | No | Dictionary of variable values, e.g. {'x': 1, 'y': 2} | |
| mode | No | Computation mode. Supports: 'evaluate', 'simplify', 'expand', 'factor' | evaluate |
| output_format | No | Output format. Supports: 'decimal', 'fraction', 'scientific', 'latex' | decimal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as non-destructive nature, input constraints, or performance characteristics. The examples only hint at usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus two examples). It is efficient but lacks structure like separate sections for purpose, usage, examples. Still, it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and that no output schema exists, the description is adequate but could be improved by specifying return type or format. It does not address differentiation from many sibling math tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 4 parameters (100% coverage). The description adds examples but no additional semantic meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does 'Mathematical expression evaluation and symbolic computation'. The examples reinforce this. However, it does not distinguish from siblings like basic_arithmetic or calculus_engine, which share similar domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites, limitations, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Professional financial mathematics calculation tool, supporting compound interest, investment analysis, risk assessment, etc.
Examples:
financial_calculator(operation='compound_interest', principal=1000, rate=0.05, time=10)
financial_calculator(operation='npv', cash_flows=[-1000, 300, 400, 500], rate=0.1)
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Financial calculation operation. Supports: 'compound_interest', 'simple_interest', 'present_value', 'future_value', 'annuity', 'npv', 'irr', 'loan_payment' | |
| principal | No | Principal or initial investment amount, must be positive | |
| rate | No | Interest rate per period (decimal format) | |
| time | No | Time period in years or number of periods | |
| cash_flows | No | Sequence of cash flows for NPV/IRR calculation | |
| initial_investment | No | Initial investment amount | |
| payment | No | Periodic payment amount | |
| periods | No | Number of payment periods | |
| future_value | No | Future value | |
| present_value | No | Present value | |
| annual_rate | No | Annualized interest rate (decimal) | |
| payments_per_year | No | Number of payments per year | |
| risk_free_rate | No | Risk-free rate for Sharpe ratio | |
| returns | No | Sequence of returns for portfolio analysis | |
| prices | No | Sequence of asset prices |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, idempotency, error handling, authentication requirements, or rate limits. For a calculation tool, it is presumably read-only, but this is not specified. The description fails to convey essential behavioral information beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief: a single sentence followed by two code examples. It is concise and front-loaded with purpose. However, it could be slightly more structured by explicitly listing the available operations instead of the vague 'etc.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has many operations and no output schema, the description does not explain return values or result structure. It does not mention whether the tool returns a single value or a complex object, which is critical for agents processing results. The examples show only function call syntax, not outputs. This leaves a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 15 parameters have descriptions in the input schema (100% coverage), so the description's additional contribution is minimal. The examples illustrate usage of 'operation' and some parameters, but do not add meaning beyond what the schema already provides. The description adequately supplements the schema without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'Professional financial mathematics calculation tool' supporting compound interest, investment analysis, risk assessment, etc. This clearly identifies the domain and purpose. However, it does not enumerate all supported operations, which are detailed in the schema. Compared to siblings like basic_arithmetic or calculus_engine, it is well differentiated as a financial calculator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No context about prerequisites, limitations, or when not to use it is given. The agent is left to infer usage solely from the tool name and examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Powerful geometry calculation tool, supporting plane geometry, solid geometry, and analytical geometry calculations.
Examples:
geometry_calculator(shape_type='circle', operation='properties', dimensions={'radius': 5})
geometry_calculator(shape_type='triangle', operation='area', points=[[0,0], [3,0], [0,4]])
| Name | Required | Description | Default |
|---|---|---|---|
| shape_type | Yes | Type of geometric shape. Supports: 'circle', 'triangle', 'rectangle', 'polygon', 'ellipse', 'sphere', 'cube', 'cylinder', 'cone', 'pyramid' | |
| operation | Yes | Geometric operation. Supports: 'area', 'volume', 'surface_area', 'circumference', 'perimeter', 'properties', 'distance', 'angle' | |
| dimensions | No | Dictionary of dimension parameters, e.g. {'radius': 5}, {'length': 10, 'width': 5} | |
| points | No | List of coordinate points for coordinate-based calculations | |
| precision | No | Number of decimal places for results | |
| unit | No | Measurement unit identifier | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention whether calculations are exact or approximate, error handling, or result format beyond examples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short with clear examples. The first sentence provides purpose, and examples are illustrative. Minor oddity: 'Brief description:' label, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not explain return values, error handling, or edge cases. For a tool with many shapes and operations, more completeness would help, but schema covers inputs well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value with examples showing real parameter combinations (e.g., radius for circle, points for triangle), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it handles plane, solid, and analytical geometry calculations, supported by clear examples. It distinguishes from sibling math tools like basic_arithmetic and calculus_engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for geometry problems but does not explicitly guide when to use this tool vs alternatives among sibling math tools. No exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Professional graph theory analysis tool, supporting shortest path, maximum flow, connectivity analysis, centrality calculation, community detection, spectral analysis, and other comprehensive graph theory functions.
Examples:
graph_theory_suite(operation='shortest_path', edge_list=[[1,2], [2,3], [1,3]], source_node=1, target_node=3)
graph_theory_suite(operation='centrality_analysis', graph_data={'nodes': [1,2,3], 'edges': [[1,2], [2,3]]})
graph_theory_suite(operation='graph_visualization', adjacency_matrix=[[0,1,1],[1,0,1],[1,1,0]], filename='graph_plot')
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Graph theory operation type. Supports: 'shortest_path', 'all_pairs_shortest_path', 'maximum_flow', 'connectivity_analysis', 'centrality_analysis', 'community_detection', 'spectral_analysis', 'graph_properties', 'minimum_spanning_tree', 'graph_coloring', 'clique_analysis', 'graph_visualization', 'graph_comparison', 'graph_generation' | |
| graph_data | No | Graph data dictionary. Format: {'nodes': [list of nodes], 'edges': [list of edges]} | |
| adjacency_matrix | No | Adjacency matrix. Square matrix, elements represent connection weights between nodes | |
| edge_list | No | Edge list. Format: [[source_node, target_node], ...] or with weights | |
| node_list | No | Node list. Used to specify node identifiers | |
| source_node | No | Source node for algorithms like shortest path | |
| target_node | No | Target node for algorithms like shortest path | |
| weight_attribute | No | Weight attribute name for weighted graph algorithms | weight |
| directed | No | Whether it is a directed graph | |
| algorithm | No | Algorithm type. E.g., 'dijkstra', 'bellman_ford' for shortest path | auto |
| k_value | No | K value for K-means clustering, K-core analysis | |
| threshold | No | Threshold value for filtering edges or nodes | |
| layout | No | Graph layout algorithm. Supports: 'spring', 'circular', 'random' | spring |
| filename | No | Save filename without path | |
| node_colors | No | List of node colors for visualization | |
| edge_colors | No | List of edge colors for visualization | |
| node_sizes | No | List of node sizes for visualization | |
| show_labels | No | Whether to show node labels in visualization | |
| figsize | No | Figure size for visualization |
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 does not disclose any behavioral traits such as side effects, authentication needs, rate limits, or computational intensity. The description is purely functional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes a brief overview followed by three examples. No extraneous text; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 19 parameters and no output schema, the description is incomplete. It does not explain what each operation returns, how parameters interact, or provide guidance on selecting the right algorithm. The examples help but are insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds examples that demonstrate parameter usage, but does not add significant semantic depth beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'professional graph theory analysis tool' supporting a list of common operations, which makes the purpose clear. However, it does not differentiate from sibling tools, though none are graph-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied by the tool's name and the listed operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Mathematical function calculation tool, supporting trigonometric, logarithmic, exponential functions, etc.
Examples:
mathematical_functions(function='sin', value=1.57, angle_unit='radians')
mathematical_functions(function='log', value=100, base=10)
| Name | Required | Description | Default |
|---|---|---|---|
| function | Yes | Mathematical function type. Supports: 'sin', 'cos', 'tan', 'asin', 'acos', 'atan', 'sinh', 'cosh', 'tanh', 'log', 'log10', 'ln', 'exp', 'sqrt', 'cbrt', 'abs', 'ceil', 'floor', 'round', 'factorial', 'gamma' | |
| value | Yes | Input value for the function | |
| base | No | Base for logarithm. Only for 'log' function, defaults to 10 | |
| precision | No | Number of decimal places for the result. Range 0-15 | |
| angle_unit | No | Angle unit. Used for trigonometric functions, supports 'radians', 'degrees' | radians |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits (e.g., read-only, error behavior, performance). It only says it 'calculates' without mentioning idempotency, edge cases, or side effects. This is too minimal for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence and two examples. It front-loads the purpose and gives practical usage patterns. Every part is useful and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and many siblings, the description is incomplete. It lacks return value explanation, error handling (e.g., invalid function, domain errors), and differentiation from similar tools like expression_evaluator or precision_calculator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds examples showing usage of base and angle_unit, but does not add meaning beyond the schema descriptions. It provides no extra context for functions, precision, or value ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it's a mathematical function calculation tool and lists supported categories (trigonometric, logarithmic, exponential). This clearly distinguishes it from siblings like basic_arithmetic (simple operations) or calculus_engine (derivatives/integrals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. Given many specialized siblings (e.g., expression_evaluator, probability_calculator), the lack of 'when not to use' leaves the agent with insufficient context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Matrix and linear algebra calculation tool, supporting basic operations and advanced analysis.
Examples:
matrix_calculator(operation='multiply', matrix_a=[[1,2],[3,4]], matrix_b=[[5,6],[7,8]])
matrix_calculator(operation='eigenvalues', matrix_a=[[4,2],[1,3]])
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Matrix operation type. Supports: 'add', 'subtract', 'multiply', 'transpose', 'determinant', 'inverse', 'rank', 'eigenvalues', 'eigenvectors', 'norm', 'trace', 'decomposition', 'solve_system', 'properties' | |
| matrix_a | Yes | Primary matrix as a 2D list | |
| matrix_b | No | Secondary matrix as a 2D list. Required for binary operations | |
| method | No | Method for decomposition. Supports: 'lu', 'qr', 'svd', 'cholesky' | |
| power | No | Power for matrix exponentiation | |
| property_type | No | Type of matrix property to analyze. Supports: 'all', 'basic', 'advanced' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as side effects, error handling, or performance characteristics. It only mentions 'basic operations and advanced analysis' without further elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but overly minimal for a complex tool with six parameters. It consists of one sentence and two examples, which is front-loaded but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description lacks completeness. It does not explain return values, result format, or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description does not add new meaning beyond repeating operation examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the tool as a 'Matrix and linear algebra calculation tool', which is a clear and specific verb+resource. It distinguishes from siblings like basic_arithmetic and calculus_engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The context of matrix operations is implied, but no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Number format conversion tool, supporting base conversion, scientific notation, etc.
Examples:
number_converter(number='255', from_base=10, to_base=16)
number_converter(number='1010', from_base=2, to_base=10)
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The number to convert (provided as a string) | |
| from_base | No | Source base. Range 2-36 | |
| to_base | No | Target base. Range 2-36 | |
| operation | No | Type of conversion operation. Supports: 'convert'(base conversion), 'format'(formatting), 'scientific'(scientific notation), 'fraction'(fraction form) | convert |
| precision | No | Precision. Number of decimal places for scientific/engineering notation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It mentions supported operations (convert, format, scientific, fraction), which is sufficient for a pure computation tool. It does not contradict any annotations (none present). However, it could mention error handling or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence and two examples. It is front-loaded with the purpose and uses minimal words without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description does not explain the return format or behavior for all operations. The examples imply a string output, but completeness could be improved by specifying output format for different operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds examples that demonstrate parameter usage, but does not provide additional semantic meaning beyond what the schema already conveys. The examples are helpful but not transformative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Number format conversion tool, supporting base conversion, scientific notation, etc.' It provides examples that illustrate usage, effectively distinguishing it from sibling tools like unit_converter or basic_arithmetic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples show typical usage, but no explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or context for choosing this tool over siblings like number_properties or expression_evaluator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Numerical property analysis tool, analyzes various mathematical properties of numbers.
Examples:
number_properties(number=17, analysis_type='comprehensive')
number_properties(number=100, analysis_type='factor')
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The number to analyze | |
| analysis_type | No | Type of analysis. Supports: 'comprehensive'(comprehensive), 'prime'(prime), 'factor'(factor), 'digital'(digital features), 'classification'(classification) | comprehensive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only says it 'analyzes properties' without mentioning side effects, return format, or computational characteristics. This is insufficient for the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes helpful examples, but the 'Brief description:' prefix is unnecessary. Overall, it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no annotations and no output schema, the description minimally covers the purpose but lacks details on return values and usage context. It is adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description's examples reinforce usage but do not add new semantic meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it analyzes 'various mathematical properties of numbers,' which is clear but broad. It does not distinguish from sibling tools like 'number_theory_calculator' or 'basic_arithmetic,' leading to some ambiguity about its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives. The examples only show basic invocations without context, so an AI agent lacks direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Advanced number theory calculation tool, supporting prime testing, factorization, modular arithmetic, etc.
Examples:
number_theory_calculator(operation='prime_factorization', number=60)
number_theory_calculator(operation='prime_test', number=97)
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Number theory operation. Supports: 'prime_factorization', 'prime_test', 'generate_primes', 'modular_arithmetic', 'extended_gcd', 'euler_totient', 'fibonacci' | |
| number | No | Primary operand, must be a positive integer | |
| numbers | No | List of numbers for operations requiring multiple numbers | |
| modulus | No | Modulus for modular arithmetic, must be positive | |
| base | No | Base for modular exponentiation | |
| exponent | No | Exponent for modular exponentiation, must be non-negative | |
| limit | No | Limit value for prime generation or fibonacci sequence | |
| precision | No | Number of terms for continued fraction expansion |
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 tool is 'advanced' and lists operations but discloses no behavioral traits (e.g., performance limits, side effects, error handling, return format).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence plus two examples) but lacks structure like bullet points or sections. However, it is efficient and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters (though only one required), no output schema, and many siblings, the description is incomplete. It doesn't explain parameter combinations, return values, or limitations for complex operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no parameter meaning beyond the schema; examples show usage but do not explain optional parameters or their interplay.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Advanced number theory calculation tool' and lists specific operations like prime testing, factorization, modular arithmetic, etc. Examples further clarify the intended usage, and the tool is well-distinguished from siblings like basic_arithmetic or calculus_engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for number theory computations but provides no explicit guidance on when to choose this tool over siblings (e.g., 'use this for number theory problems'). No exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Professional optimization suite, supporting function optimization, constraint optimization, root finding, and linear programming.
Examples:
optimization_suite(objective_function='x**2 + y**2', variables=['x', 'y'], operation='minimize')
optimization_suite(equation='x**2 - 4', operation='find_roots')
| Name | Required | Description | Default |
|---|---|---|---|
| objective_function | No | Objective function expression to optimize | |
| variables | No | List of optimization variables | |
| operation | No | Optimization operation. Supports: 'minimize', 'maximize', 'find_roots', 'linear_programming' | minimize |
| method | No | Optimization method. Supports: 'auto', 'nelder_mead', 'powell', 'bfgs', 'lbfgs', 'differential_evolution' | auto |
| initial_guess | No | Initial guess for optimization variables | |
| bounds | No | Bounds for variables as list of (min, max) tuples | |
| constraints | No | Constraint definitions as list of dictionaries | |
| equation | No | Equation to solve for root finding | |
| root_method | No | Root finding method. Supports: 'fsolve', 'brentq', 'newton' | fsolve |
| lp_c | No | Coefficients for linear programming objective | |
| lp_A_ub | No | Inequality constraint matrix for linear programming | |
| lp_b_ub | No | Inequality constraint bounds for linear programming | |
| lp_A_eq | No | Equality constraint matrix for linear programming | |
| lp_b_eq | No | Equality constraint bounds for linear programming |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the purpose and operations. It does not disclose behavioral traits such as prerequisites, failure states, or return format, which is minimal for a complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief purpose and two examples. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 14 parameters and multiple operations, the description lacks guidance on parameter selection per operation and does not mention output format. The examples are helpful but insufficient for complete usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond schema via examples, but does not explain complex parameters like constraints or bounds in depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'professional optimization suite' supporting multiple operations (function optimization, constraint optimization, root finding, linear programming), which distinguishes it from sibling math tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples show usage for minimization and root finding, but no explicit guidance on when to use this tool over siblings or when not to use it. The context is implied but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Mathematical function curve plotting tool, supporting function graph visualization and derivative analysis.
Examples:
plot_function_curve(function_expression='x**2 + 2*x + 1')
plot_function_curve(function_expression='sin(x)', x_range=(-6.28, 6.28), filename='sine_wave')
| Name | Required | Description | Default |
|---|---|---|---|
| function_expression | Yes | Function expression with common math functions like sin, cos, exp, log, sqrt | |
| variable | No | Independent variable name | x |
| x_range | No | X-axis range as (min_value, max_value) | |
| num_points | No | Number of plotting points | |
| title | No | Chart title | Function Graph |
| xlabel | No | X-axis label | X Axis |
| ylabel | No | Y-axis label | Y Axis |
| filename | No | Save filename without path and extension | |
| format | No | Image format. Supports: 'png', 'jpg', 'svg' | png |
| figsize | No | Figure size as (width, height) | |
| dpi | No | Image resolution | |
| color | No | Function curve color | blue |
| line_width | No | Line width | |
| grid | No | Whether to display grid | |
| grid_alpha | No | Grid transparency | |
| derivative_order | No | Derivative order for plotting n-th derivative curve | |
| show_critical_points | No | Whether to show critical points (extrema) | |
| show_equation | No | Whether to display function equation on plot | |
| equation_position | No | Equation display position. Supports: 'upper right', 'upper left', 'lower right', 'lower left' | upper right |
| alpha | No | Line transparency | |
| line_style | No | Line style | - |
| marker | No | Data point marker | |
| marker_size | No | Marker size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It mentions derivative analysis but does not disclose what the tool returns (e.g., saves an image, displays plot, returns file path), error handling, or side effects. The examples suggest saving a file, but the behavior is not described in prose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two lines and two examples, but it includes the redundant phrase 'Brief description'. The examples provide clear usage patterns. Overall, it is efficient but could be more structured with bullet points or a clearer separation of behavior and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (23 parameters, 1 required), the description is insufficient. It does not explain what the tool outputs (e.g., file path, image data), how to handle derivative orders, or provide context for advanced features like critical points. The examples help but are not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the baseline is 3. The description adds no additional meaning beyond the schema; it only repeats the tool's high-level purpose. For instance, derivative analysis is mentioned but not linked to the 'derivative_order' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: plotting mathematical function curves and supporting derivative analysis. It uses a specific verb ('plot') and resource ('mathematical function curve'), and the examples reinforce this. The sibling tools include more generic charting and calculus tools, but the description effectively distinguishes this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like 'calculus_engine' for derivative calculations or 'create_and_save_chart' for general plotting. There is no mention of prerequisites, limitations, or explicit when-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: High-precision numerical calculation tool, supporting arithmetic operations with arbitrary precision.
Examples:
precision_calculator(numbers=[1.123, 2.987], operation='add', precision_digits=15)
precision_calculator(numbers=[2], operation='sqrt', precision_digits=20)
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | Yes | List of numerical values for calculation | |
| operation | Yes | Operation type. Supports: 'add', 'subtract', 'multiply', 'divide', 'power', 'sqrt', 'factorial' | |
| precision_digits | No | Number of precision digits | |
| rounding_mode | No | Rounding mode. Supports: 'round_half_up', 'round_down', etc. | round_half_up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description fails to disclose behavioral traits such as error handling, performance implications, or that certain operations (e.g., sqrt) may only work with single numbers. The 'arbitrary precision' claim lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a brief summary and two useful examples. However, it lacks a structured breakdown of when to use or parameter details, which would improve usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description does not fully explain return value format, constraints (e.g., operation 'sqrt' requires a single number), or edge cases. It leaves ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters (100% coverage), so the description is not required to add much. The examples illustrate valid inputs, but no additional meaning is added beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it as a high-precision calculation tool with arbitrary precision, and the examples show specific operations. However, it does not explicitly differentiate itself from siblings like 'basic_arithmetic' or 'expression_evaluator' beyond mentioning precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, not when to prefer it over other math tools listed as siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Probability and statistics calculation tool, supporting probability distributions, hypothesis testing, Bayesian analysis, etc.
Examples:
probability_calculator(operation='probability_mass', distribution='normal', parameters={'mu':0,'sigma':1}, x_value=1.96)
probability_calculator(operation='cumulative_distribution', distribution='normal', parameters={'mu':20,'sigma':3}, x_value=25)
probability_calculator(operation='random_sampling', distribution='binomial', parameters={'n':10,'p':0.3}, n_samples=100)
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Probability/statistics operation. Supports: 'probability_mass', 'cumulative_distribution', 'random_sampling', 'bayes_theorem', 'hypothesis_test' | |
| distribution | No | Probability distribution. Supports: 'normal', 'binomial', 'poisson', 'uniform', 'exponential' | |
| parameters | No | Distribution parameters, e.g. {'mean': 0, 'std': 1} | |
| x_value | No | Single value for probability calculation | |
| x_values | No | Multiple values for calculation | |
| probability | No | Probability value for inverse calculations | |
| n_samples | No | Number of samples for random sampling | |
| events | No | List of events for Bayesian analysis | |
| data | No | Data for statistical testing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only gives examples but does not mention side effects, error behavior, performance, or that it is a read-only calculation. This is insufficient for a complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: one sentence and three examples. It is front-loaded with purpose. However, structure could be improved by adding a separate section for behavior or return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return format, error handling, or constraints. Examples provide some context but not enough for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool description adds examples but no new semantic meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a probability and statistics calculation tool, supporting distributions, hypothesis testing, Bayesian analysis. Examples clarify operations. This distinguishes it from siblings like basic_arithmetic and calculus_engine, but could be more specific vs. statistics_analyzer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives like statistics_analyzer or regression_modeler. The description implies usage for probability/statistics but does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Regression analysis and machine learning modeling tool, supporting various regression algorithms and prediction functions.
Examples:
regression_modeler(operation='fit', x_data=[[1], [2], [3]], y_data=[2, 4, 6], model_type='linear')
regression_modeler(operation='predict', x_data=[[12]], training_x=[[1], [2], [3]], training_y=[2, 4, 6])
| Name | Required | Description | Default |
|---|---|---|---|
| operation | No | Regression operation type. Supports: 'fit', 'predict', 'residual_analysis', 'model_comparison' | fit |
| x_data | No | Independent variable data as 2D list | |
| y_data | No | Dependent variable data as 1D list | |
| model_type | No | Regression model type. Supports: 'linear', 'polynomial', 'ridge', 'lasso', 'elastic_net', 'logistic' | linear |
| degree | No | Degree for polynomial regression | |
| alpha | No | Regularization parameter | |
| l1_ratio | No | Elastic Net L1 ratio | |
| cv_folds | No | Number of cross-validation folds | |
| test_size | No | Test set proportion | |
| y_true | No | True values for residual analysis | |
| y_pred | No | Predicted values for residual analysis | |
| models_results | No | List of model results for comparison | |
| training_x | No | Training independent variable data | |
| training_y | No | Training dependent variable data | |
| model_params | No | Pre-trained model parameters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'regression analysis and machine learning modeling tool' without mentioning statefulness, side effects, or resource usage. The examples imply stateless invocation but no explicit confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose. The examples are useful but slightly verbose; removing 'Brief description:' would improve conciseness. Overall, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, multiple operations), the description is inadequate. It does not explain the workflow (e.g., fitting before predicting) or detail operations like residual_analysis and model_comparison. No output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no further semantic value beyond the schema descriptions; the examples show common parameter combinations but do not clarify all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a regression analysis and machine learning modeling tool, supporting various algorithms and prediction functions. This distinguishes it from sibling tools like basic_arithmetic or statistics_analyzer, though the latter might overlap. The examples clarify fit and predict operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like statistics_analyzer or optimization_suite. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Professional digital signal processing tool, supporting FFT, filtering, modulation/demodulation, etc.
Examples:
signal_processing_calculator(operation='generate_signal', signal_type='sine', frequency=10, sampling_rate=1000, duration=1)
signal_processing_calculator(operation='fft', signal=[1,2,3,4,5,6,7,8], sampling_rate=8)
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Signal processing operation. Supports: 'fft', 'generate_signal', 'filter', 'windowing', 'autocorrelation', 'spectral_analysis', 'modulation' | |
| signal | No | Input signal data for small datasets (<1000 points) | |
| signal_file | No | Signal file path (.json format) for large data processing | |
| sampling_rate | No | Sampling rate in Hz, must be positive | |
| frequency | No | Signal frequency in Hz for generation/modulation | |
| filter_type | No | Filter type. Supports: 'lowpass', 'highpass', 'bandpass', 'moving_average' | |
| cutoff_freq | No | Cutoff frequency in Hz for filtering | |
| window_size | No | Window size for windowing/spectral analysis | |
| overlap | No | Window overlap ratio for spectral analysis | |
| order | No | Filter order | |
| duration | No | Signal duration in seconds for generation | |
| noise_level | No | Noise amplitude for signal generation | |
| signal_type | No | Signal type for generation. Supports: 'sine', 'cosine', 'square', 'sawtooth', 'white_noise' | |
| output_filename | No | Output filename without path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose behavioral traits like side effects, required permissions, limitations (e.g., data size handling via signal_file is only in schema), or return value structure. The description only lists operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief sentence and two examples. It is front-loaded with the purpose. However, it could be more structured by separating the summary from examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, no output schema, and no annotations, the description is insufficient. It lacks information on return values, error handling, and parameter selection logic (e.g., when to use signal vs signal_file).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds examples that illustrate parameter combinations but does not add new meaning beyond the schema's parameter descriptions. The examples are helpful but not essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a professional digital signal processing tool supporting operations like FFT, filtering, modulation, etc. The examples reinforce this. It distinguishes itself from sibling tools like basic_arithmetic or calculus_engine by focusing on signal processing, though the description is broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it. The examples only show syntax, not decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Comprehensive statistical analysis tool, supporting descriptive statistics, hypothesis testing, and distribution analysis.
Examples:
statistics_analyzer(data1=[1,2,3,4,5], analysis_type='descriptive')
statistics_analyzer(data1=[1,2,3], data2=[4,5,6], analysis_type='comparison')
| Name | Required | Description | Default |
|---|---|---|---|
| data1 | Yes | Primary dataset for analysis | |
| analysis_type | Yes | Type of statistical analysis. Supports: 'descriptive', 'distribution', 'hypothesis_test', 'correlation', 'regression', 'comparison' | |
| data2 | No | Secondary dataset for comparison operations | |
| test_type | No | Statistical test type. Supports: 't_test', 'chi_square', 'anova', 'kolmogorov_smirnov' | |
| hypothesis_test_type | No | Hypothesis test variant. Supports: 'one_sample', 'two_sample', 'paired' | |
| confidence | No | Confidence level | |
| distribution_type | No | Distribution type for analysis. Supports: 'normal', 'binomial', 'poisson' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects, memory usage, required permissions, or what happens with invalid inputs. The description is too minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes examples immediately. It is front-loaded with the purpose and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description is insufficient. It lacks details on return values, error handling, and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds example usage but does not provide additional semantic detail beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for 'comprehensive statistical analysis' and lists examples of use. However, it does not differentiate from sibling tools like 'regression_modeler' or 'complex_analysis_suite', which might offer similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description provides examples but no context about prerequisites, data size limits, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brief description: Physical unit conversion tool, supporting length, weight, temperature, etc., unit conversions.
Examples:
unit_converter(value=100, from_unit='cm', to_unit='m', unit_type='length')
unit_converter(value=32, from_unit='fahrenheit', to_unit='celsius', unit_type='temperature')
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The numerical value to convert | |
| from_unit | Yes | Source unit | |
| to_unit | Yes | Target unit | |
| unit_type | Yes | Unit type. Supports: 'length', 'weight', 'temperature', 'area', 'volume', 'time', 'speed', 'energy' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose limitations, accuracy, supported conversion types beyond a few examples, or any special behavior. It relies heavily on the schema for detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, including a brief purpose and two examples. It is well-structured and front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no nested objects or output schema, the description covers the basics but omits some detail (e.g., incomplete list of unit types in the description). It is adequate but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides full parameter descriptions (100% coverage). The description adds value with concrete examples showing how to invoke the tool, which aids understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a physical unit conversion tool supporting length, weight, temperature, etc., with examples. This distinguishes it from sibling tools like basic_arithmetic or calculus_engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through examples and the brief description, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.3basic_arithmeticcalculus_enginecleanup_resourcescomplex_analysis_suitecreate_and_save_chartexpression_evaluatorfinancial_calculatorgeometry_calculatorgraph_theory_suitemathematical_functionsmatrix_calculatornumber_converternumber_propertiesnumber_theory_calculatoroptimization_suiteplot_function_curveprecision_calculatorprobability_calculatorregression_modelersignal_processing_calculatorstatistics_analyzerunit_converterMost tools have clearly distinct purposes covering different mathematical domains. Potential confusion exists between number_properties and number_theory_calculator, and between expression_evaluator and mathematical_functions, but descriptions help differentiate them.
Naming conventions are mixed: some use noun_descriptor (e.g., calculus_engine), others use verb_noun (e.g., plot_function_curve), and there is inconsistency in the use of 'calculator' vs 'engine' vs 'suite'. While mostly readable, the pattern is not strongly consistent.
22 tools is on the high side for a math server, but still within reason given the breadth of topics covered (arithmetic, calculus, statistics, etc.). Some tools like signal_processing_calculator and graph_theory_suite are very specialized, so the count could be slightly trimmed without losing core functionality.
The tool surface is remarkably comprehensive, covering all major mathematical areas: basic operations, algebra, calculus, geometry, linear algebra, number theory, statistics, probability, optimization, complex analysis, graph theory, and even financial math. The inclusion of a cleanup utility is a minor oddity, but does not detract from the strong coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Math.js MCP — wraps the mathjs.org API (free, no auth)
QuLab MCP remote server (Streamable HTTP) for computational science and lab tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/111-test-111/math-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server