Math MCP Learning
Server Details
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- clouatre-labs/math-mcp-learning-server
- GitHub Stars
- 2
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 17 of 17 tools scored. Lowest: 3.1/5.
Each tool has a distinct purpose: calculation, statistics, unit conversion, matrix operations, plotting, and workspace management. No overlapping functionality between tools.
Tools follow consistent prefixes: calc_ for calculations, matrix_ for matrices, plot_ for plots, workspace_ for persistence. No mixing of conventions.
17 tools cover the domain well without being excessive. Each tool serves a clear need in a math learning context.
Covers core areas (calculations, statistics, matrices, plotting, workspace) but lacks more advanced topics like calculus, probability, or correlation/regression.
Available Tools
17 toolscalc_expressionMathematical CalculatorARead-onlyIdempotentInspect
Safely evaluate mathematical expressions with support for basic operations and math functions.
Supported operations: +, -, *, /, **, () Supported functions: sin, cos, tan, log, sqrt, abs, pow
Note: Use this tool to evaluate a single mathematical expression. To compute descriptive statistics over a list of numbers, use the statistics tool instead.
Examples:
"2 + 3 * 4" → 14
"sqrt(16)" → 4.0
"sin(3.14159/2)" → 1.0
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | Mathematical expression to evaluate. Supports +, -, *, /, **, and math functions (sin, cos, sqrt, log, etc.). Example: '2 * sin(pi/4) + sqrt(16)' |
Output Schema
| Name | Required | Description |
|---|---|---|
| topic | Yes | |
| result | Yes | |
| difficulty | Yes | |
| expression | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds context like 'Safely evaluate' and lists math functions, but no additional behavioral traits beyond schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet complete: first sentence states purpose, then supported ops, usage note, examples. No wasted 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?
Single parameter fully documented, output schema exists (so return values not needed), sibling tools are different, and usage guidance is provided. Complete.
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 has 100% coverage with detailed description, and description adds examples and lists functions explicitly, enhancing understanding beyond 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 the tool evaluates mathematical expressions, listing supported operations and functions. It distinguishes from sibling tools by referencing calc_statistics for descriptive statistics.
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?
Explicitly says when to use (single expression) and when not (descriptive statistics should use statistics tool), with examples and supported operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calc_interestCompound Interest CalculatorARead-onlyIdempotentInspect
Calculate compound interest for investments.
Formula: A = P(1 + r/n)^(nt) Where:
P = principal amount
r = annual interest rate (as decimal)
n = number of times interest compounds per year
t = time in years
Examples: compound_interest(10000, 0.05, 5) # $10,000 at 5% for 5 years → $12,762.82 compound_interest(5000, 0.03, 10, 12) # $5,000 at 3% compounded monthly → $6,744.25
| Name | Required | Description | Default |
|---|---|---|---|
| rate | Yes | Annual interest rate as decimal 0.0-1.0 (e.g. 0.05 = 5%). If entering a percentage, divide by 100 first. | |
| time | Yes | Investment time in years (must be > 0), e.g. 10.0 | |
| principal | Yes | Initial investment amount in dollars (must be > 0), e.g. 1000.0 | |
| compounds_per_year | No | Compounding frequency per year (must be > 0): 12=monthly, 365=daily |
Output Schema
| Name | Required | Description |
|---|---|---|
| rate | Yes | |
| time | Yes | |
| topic | Yes | |
| formula | Yes | |
| principal | Yes | |
| difficulty | Yes | |
| final_amount | Yes | |
| total_interest | Yes | |
| compounds_per_year | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint are true. The description adds behavioral context by explaining the formula and providing examples, without contradicting annotations. No side effects or destructive actions.
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, well-structured with formula, parameter explanations, and two useful examples. Every sentence serves a 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?
While the description covers input and purpose well, and output schema exists (so return values are explained elsewhere), there is no guidance on edge cases like zero principal or negative time. However, for a standard calculator, it is fairly complete.
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?
Input schema already has 100% coverage with descriptions. The description adds value by restating the formula and providing concrete examples, mapping parameters to their roles. This enhances understanding beyond the 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 the tool calculates compound interest for investments, with the formula and examples. It is distinct from sibling tools like calc_expression (general expressions) and calc_statistics.
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 formula and examples for compound interest, but does not explicitly state when not to use it or when to prefer alternatives like calc_expression or other financial tools. However, the context of sibling tools makes the purpose clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calc_statisticsStatistical AnalysisARead-onlyIdempotentInspect
Perform statistical calculations on a list of numbers.
Available operations: mean, median, mode, std_dev, variance
Note: Use this tool to compute descriptive statistics over a list of numbers. To evaluate a single mathematical expression, use the calculate tool instead.
Examples: statistics([1.0, 2.5, 3.0, 4.5, 5.0], "mean") # Returns 3.2 statistics([1.0, 2.5, 3.0, 4.5, 5.0], "std_dev") # Returns ~1.58
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | Yes | List of numbers to compute descriptive statistics on. Example: [1.0, 2.5, 3.0, 4.5, 5.0] | |
| operation | Yes | Statistical operation to perform. Allowed values: mean, median, mode, std_dev, variance |
Output Schema
| Name | Required | Description |
|---|---|---|
| topic | Yes | |
| result | Yes | |
| operation | Yes | |
| difficulty | Yes | |
| sample_size | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description does not need to reiterate safety. The description adds that it computes descriptive statistics, which is consistent and non-contradictory.
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 well-structured: purpose first, then operations list, then usage note, and finally examples. Every sentence is informative and 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 simplicity, annotations, full schema coverage, and presence of output schema, the description provides complete contextual information with examples and usage guidance.
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?
Input schema has 100% coverage with descriptions and examples for both parameters. The description supplements with usage examples, adding value 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 that the tool performs statistical calculations on a list of numbers, lists the specific operations (mean, median, mode, std_dev, variance), and distinguishes itself from the 'calculate' tool for single expressions.
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 explicitly says to use this tool for descriptive statistics over a list of numbers and advises to use the 'calculate' tool for single mathematical expressions, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calc_unitsUnit ConverterARead-onlyIdempotentInspect
Convert between different units of measurement.
Supported unit types:
length: mm, cm, m, km, in, ft, yd, mi
weight: g, kg, oz, lb
temperature: c, f, k (Celsius, Fahrenheit, Kelvin)
Examples: convert_units(5, "km", "mi", "length") # 5 kilometers → 3.11 miles convert_units(150, "lb", "kg", "weight") # 150 pounds → 68.04 kilograms
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Numeric value to convert, e.g., 100.0 | |
| to_unit | Yes | Target unit abbreviation. Valid units depend on unit_type: length (mm, cm, m, km, in, ft, yd, mi), weight (g, kg, oz, lb), temperature (c, f, k) | |
| from_unit | Yes | Source unit abbreviation. Valid units depend on unit_type: length (mm, cm, m, km, in, ft, yd, mi), weight (g, kg, oz, lb), temperature (c, f, k) | |
| unit_type | Yes | Unit category: length, weight, or temperature |
Output Schema
| Name | Required | Description |
|---|---|---|
| topic | Yes | |
| value | Yes | |
| to_unit | Yes | |
| from_unit | Yes | |
| unit_type | Yes | |
| difficulty | Yes | |
| converted_value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true, indicating safe, deterministic behavior. The description adds context on supported unit types and conversion details, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief purpose statement, a bulleted list of unit types, and formatted examples. No unnecessary words or repetition.
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 presence of an output schema and complete parameter descriptions, the description provides sufficient context about supported conversions and usage patterns. No need to explain return values as output schema exists.
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 already covers all parameters with 100% description coverage, listing valid units for each parameter. The description adds examples and groups units by type, but these are already implied in 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 the tool converts between different units of measurement, lists supported unit types (length, weight, temperature) with specific abbreviations, and provides concrete examples. This distinguishes it from sibling tools like calc_expression and matrix_inverse, which are for calculations and matrix 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?
The description implies usage for unit conversion by listing supported types and examples. It does not explicitly exclude scenarios or mention alternatives, but the examples and listing of sibling tools in the context signal provide clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
matrix_determinantMatrix DeterminantARead-onlyIdempotentInspect
Calculate the determinant of a square matrix.
Note: Requires NumPy. Raises ValueError if NumPy is unavailable.
Examples: matrix_determinant([[1, 2], [3, 4]]) matrix_determinant([[1, 0, 0], [0, 1, 0], [0, 0, 1]]) # Identity matrix
| Name | Required | Description | Default |
|---|---|---|---|
| matrix | Yes | 2D list of numbers representing a square matrix. Each inner list is a row. Example: [[1, 2], [3, 4]] |
Output Schema
| Name | Required | Description |
|---|---|---|
| size | Yes | |
| topic | Yes | |
| difficulty | Yes | |
| determinant | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds valuable context: it requires NumPy and can raise a ValueError if not available. The examples provide concrete use cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with three sentences and examples. It is front-loaded with the main purpose. Every sentence adds value, though it could be slightly tighter.
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 simplicity of the tool (one parameter), the description covers the main purpose, dependency, and examples. The output schema is not shown but is indicated to exist, so return value information is not needed. Minor gap: does not explicitly state what happens for non-square matrices, but it is implied they would cause an error.
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 a clear description of the matrix parameter. The description's examples reinforce the schema but do not add new meaning beyond what the schema already 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 states the tool calculates the determinant of a square matrix. The verb 'calculate' and resource 'determinant of a square matrix' are specific. It distinguishes from sibling tools like matrix_inverse and matrix_eigenvalues.
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. The note about requiring NumPy is a prerequisite but doesn't help an agent choose between determinant and other matrix operations. Sibling tools exist but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
matrix_eigenvaluesMatrix EigenvaluesARead-onlyIdempotentInspect
Calculate the eigenvalues of a square matrix.
Note: Requires NumPy. Raises ValueError if NumPy is unavailable.
Examples: matrix_eigenvalues([[4, 2], [1, 3]]) matrix_eigenvalues([[3, 0, 0], [0, 5, 0], [0, 0, 7]]) # Diagonal matrix
| Name | Required | Description | Default |
|---|---|---|---|
| matrix | Yes | 2D list of numbers representing a square matrix. Each inner list is a row. Example: [[4, 2], [1, 3]] |
Output Schema
| Name | Required | Description |
|---|---|---|
| size | Yes | |
| error | No | |
| topic | Yes | |
| success | Yes | |
| difficulty | Yes | |
| eigenvalues | No | |
| eigenvectors | No | |
| complex_values | No | |
| complex_eigenvalues_warning | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds the requirement for NumPy and the ValueError behavior, which is useful beyond the annotations. No contradiction.
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 only essential information: function, requirement, error, and examples. Every sentence adds value, and it 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 low complexity (1 parameter) and the presence of an output schema, the description covers requirements, error handling, and examples. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description includes examples that illustrate usage, but the schema already details the matrix parameter format. No extra semantic information 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 'Calculate the eigenvalues of a square matrix,' specifying the verb and resource. It distinguishes from sibling matrix tools like matrix_determinant and matrix_inverse.
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 mentions the requirement for NumPy and the error case, but does not explicitly state when to use or avoid this tool compared to siblings. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
matrix_inverseMatrix InverseARead-onlyIdempotentInspect
Calculate the inverse of a square matrix.
Note: Requires NumPy. Raises ValueError if NumPy is unavailable.
Examples: matrix_inverse([[1, 2], [3, 4]]) matrix_inverse([[2, 0], [0, 2]]) # Diagonal matrix
| Name | Required | Description | Default |
|---|---|---|---|
| matrix | Yes | 2D list of numbers representing a square matrix. Each inner list is a row. Example: [[1, 2], [3, 4]] |
Output Schema
| Name | Required | Description |
|---|---|---|
| size | Yes | |
| error | No | |
| topic | Yes | |
| success | Yes | |
| difficulty | Yes | |
| result_matrix | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent behavior. The description adds the NumPy dependency error and examples, but does not disclose edge cases (e.g., singular matrix) or return format. Adequate but not rich.
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 the purpose statement. Note and examples are useful without being verbose. Could be slightly more concise by removing redundant 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?
Given low complexity, high schema coverage, presence of output schema, and clear sibling set, the description covers basic usage and the main error condition. Missing return value description but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema describes the matrix parameter fully. The description adds examples and a note about NumPy, but these mostly duplicate the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Calculate the inverse of a square matrix,' providing a specific verb and resource. This clearly distinguishes it from sibling tools like matrix_determinant and matrix_multiply.
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 includes a note about NumPy dependency and raises ValueError if unavailable, but does not provide guidance on when to use this tool versus alternatives like matrix_determinant (e.g., checking invertibility). No explicit when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
matrix_multiplyMatrix MultiplicationARead-onlyIdempotentInspect
Multiply two matrices (A × B).
Note: Requires NumPy. Raises ValueError if NumPy is unavailable.
Examples: matrix_multiply([[1, 2], [3, 4]], [[5, 6], [7, 8]]) matrix_multiply([[1, 2, 3]], [[1], [2], [3]])
| Name | Required | Description | Default |
|---|---|---|---|
| matrix_a | Yes | 2D list of numbers representing the first matrix. Each inner list is a row. Example: [[1, 2], [3, 4]] | |
| matrix_b | Yes | 2D list of numbers representing the second matrix. Each inner list is a row. Example: [[5, 6], [7, 8]] |
Output Schema
| Name | Required | Description |
|---|---|---|
| topic | Yes | |
| cols_a | Yes | |
| cols_b | Yes | |
| rows_a | Yes | |
| rows_b | Yes | |
| difficulty | Yes | |
| result_matrix | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, already indicating safe operation. Description adds useful behavior: requires NumPy and raises ValueError if unavailable, plus examples demonstrating correct 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?
Extremely concise: one sentence for purpose, one note, two examples. No wasted words; front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that matrix multiplication typically returns a matrix, the description does not specify the output format or shape. With 100% schema coverage and presence of output schema (indicated), some expectation of return value description is missing.
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 detailed descriptions for both parameters, including examples. The description's examples mirror the schema but add no new semantic meaning beyond what's in 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 'Multiply two matrices (A × B)' clearly states the verb and resource, distinguishing it from sibling matrix operations like determinant, eigenvalues, etc.
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. Only a note about NumPy requirement and error, but no context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
matrix_transposeMatrix TransposeARead-onlyIdempotentInspect
Transpose a matrix (swap rows and columns).
Note: Requires NumPy. Raises ValueError if NumPy is unavailable.
Examples: matrix_transpose([[1, 2, 3], [4, 5, 6]]) matrix_transpose([[1], [2], [3]])
| Name | Required | Description | Default |
|---|---|---|---|
| matrix | Yes | 2D list of numbers representing the matrix. Each inner list is a row. Example: [[1, 2, 3], [4, 5, 6]] |
Output Schema
| Name | Required | Description |
|---|---|---|
| topic | Yes | |
| difficulty | Yes | |
| original_cols | Yes | |
| original_rows | Yes | |
| result_matrix | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by warning about ValueError when NumPy is missing, which is beyond annotation info.
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?
Extremely concise: two sentences and two examples. Every sentence is purposeful, with no redundant 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 complete schema coverage and an output schema, the description covers purpose, dependency, and examples adequately. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and clearly documents the matrix parameter. The description provides usage examples but does not add significant new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Transpose' and the resource 'matrix', clearly stating the operation. It effectively distinguishes from sibling tools like matrix_determinant and matrix_inverse.
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 and a note on NumPy dependency but does not discuss context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plot_box_plotBox PlotARead-onlyIdempotentInspect
Create a box plot for comparing distributions (requires matplotlib).
Examples: plot_box_plot([[1, 2, 3, 4, 5], [2, 4, 6, 8, 10]], group_labels=["A", "B"]) plot_box_plot([[10, 20, 30], [15, 25, 35], [5, 15, 25]], title="Comparison")
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Box color (name or hex code, e.g., 'blue', '#2E86AB') | |
| title | No | Chart title string, e.g., 'Distribution Comparison' | Box Plot |
| y_label | No | Y-axis label, e.g., 'Values' | Values |
| data_groups | Yes | List of data groups to compare, e.g., [[1, 2, 3], [4, 5, 6]] | |
| group_labels | No | Labels for each group, e.g., ['Group A', 'Group B'] |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's addition of 'requires matplotlib' provides useful dependency context beyond what annotations offer. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence followed by two illustrative examples. Every element serves a purpose with no redundancy, 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?
The description covers purpose and provides examples for a tool with 5 parameters and no output schema. It does not explicitly state the output type (plot object), but the readOnlyHint and idempotentHint imply a safe, repeatable operation. Slight gap but still strong.
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?
With 100% schema description coverage, the baseline is 3. The description adds value through examples that demonstrate typical usage of data_groups, group_labels, and title, making parameter semantics clearer than the 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 explicitly states 'Create a box plot for comparing distributions', which is a specific verb-resource combination. The examples further clarify the input format and distinguish it from sibling tools like histogram or line chart.
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 mentions 'requires matplotlib' as a prerequisite but does not explicitly state when to use this tool versus alternatives like plot_histogram. Usage context is only implied by the tool name and examples, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plot_financial_lineFinancial Line ChartARead-onlyIdempotentInspect
Generate and plot synthetic financial price data (requires matplotlib).
Creates realistic price movement patterns for educational purposes. Does not use real market data.
Note: Use for time-series price data with optional moving average overlay. For general XY data, use plot_line_chart instead.
Examples: plot_financial_line(days=60, trend='bullish') plot_financial_line(days=90, trend='volatile', start_price=150.0, color='orange')
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to generate, e.g., 30 | |
| color | No | Line color (name or hex code, e.g., 'blue', '#2E86AB') | |
| trend | No | Market trend direction | bullish |
| start_price | No | Starting price value, e.g., 100.0 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it uses synthetic data ('Does not use real market data') and is for educational purposes, which are beneficial context beyond the annotations. No inconsistencies found.
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: three short paragraphs covering purpose, usage, and examples. Every sentence adds value, and examples are front-loaded for quick comprehension.
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 moderate complexity (4 parameters, no output schema), the description adequately covers the input parameters, educational use case, and matplotlib dependency. It lacks explicit mention of the output (a matplotlib plot) but implies it. This is sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description provides examples showing parameter usage (e.g., 'plot_financial_line(days=60, trend='bullish')'). However, it does not add significant extra meaning beyond the schema's descriptions, so a baseline 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 'Generate and plot synthetic financial price data', clearly indicating the tool produces simulated financial charts. It distinguishes from sibling 'plot_line_chart' by specifying it's for time-series price data with optional moving average, while the sibling handles general XY data.
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?
Explicitly advises 'Use for time-series price data with optional moving average overlay. For general XY data, use plot_line_chart instead.' and notes the matplotlib dependency. This provides clear when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plot_functionFunction PlotterARead-onlyIdempotentInspect
Generate mathematical function plots (requires matplotlib).
Examples: plot_function("x**2", (-5, 5)) plot_function("sin(x)", (-3.14, 3.14))
| Name | Required | Description | Default |
|---|---|---|---|
| x_range | Yes | X-axis range as (min, max), e.g., (-5.0, 5.0) | |
| expression | Yes | Mathematical expression to plot, e.g., "x**2" or "sin(x)". Must be <= MAX_EXPRESSION_LENGTH characters. Example: "x**2" | |
| num_points | No | Number of sample points to plot along x_range, e.g., 100 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so description doesn't repeat those. The description adds that it requires matplotlib, which is important dependency information beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus two short example calls. No redundant information. Every piece earns its place—title, core function, dependency, and usage examples are all 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?
The tool is simple (3 parameters, all documented). The description lacks explicit mention of return type (presumably a plot), but given no output schema and low complexity, the examples imply the output. With annotations covering safety and idempotency, the description is sufficiently complete.
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 by providing concrete examples (e.g., 'x**2', 'sin(x)') that clarify the expected format for 'expression' and 'x_range', improving 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 'Generate mathematical function plots,' clearly differentiating from sibling tools that plot data or perform calculations. The verb 'generate' combined with 'mathematical function plots' precisely describes the tool's action and resource.
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 usage context with examples, but does not explicitly mention when not to use this tool or suggest alternatives among siblings. However, the examples and title make it clear this is for mathematical expressions, not general data plotting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plot_histogramStatistical HistogramARead-onlyIdempotentInspect
Create statistical histograms (requires matplotlib).
Examples: plot_histogram([1.0, 2.0, 2.5, 3.0, 3.5, 4.0, 5.0]) plot_histogram([10, 20, 30, 40, 50], bins=5, title="Test Scores")
| Name | Required | Description | Default |
|---|---|---|---|
| bins | No | Number of histogram bins, e.g., 20 | |
| data | Yes | List of numeric values to bin, e.g., [1.0, 2.0, 2.5, 3.0] | |
| title | No | Chart title string, e.g., 'Data Distribution' | Data Distribution |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint true, so the tool is safe to invoke repeatedly. The description adds context about requiring matplotlib, which is a dependency. It does not contradict annotations, and the examples show expected invocation patterns, though no side effects like displaying or saving the plot are mentioned.
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: two lines plus two examples. Every word serves a purpose, and the examples immediately clarify the tool's use. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creating a histogram) and the lack of an output schema, the description could mention that the histogram is displayed (likely via matplotlib's show) or saved to a file. It does not explain the behavioral outcome or side effects, which is a gap for a tool that modifies the display environment. However, the examples provide minimal 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?
Schema coverage is 100%, so the baseline is 3. The description provides examples that illustrate parameter usage (e.g., bins=5, title='Test Scores'), but it does not add significant meaning beyond the schema descriptions, which already cover data types, defaults, and constraints.
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: 'Create statistical histograms (requires matplotlib).' It specifies the verb (create) and resource (histograms), and the examples reinforce this. It distinguishes from sibling tools like plot_line_chart or plot_scatter by being explicitly for histograms.
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 of usage but does not explicitly state when to use this tool vs alternatives (e.g., plot_box_plot for distributions with outliers). The 'statistical' qualifier hints at its use for data distribution, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plot_line_chartLine ChartARead-onlyIdempotentInspect
Create a line chart from data points (requires matplotlib).
Note: Use for general XY data. For time-series price data with optional moving average, use plot_financial_line instead.
Examples: plot_line_chart([1, 2, 3, 4], [1, 4, 9, 16], title="Squares") plot_line_chart([0, 1, 2], [0, 1, 4], color='red', x_label='Time', y_label='Distance')
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Line color (name or hex code, e.g., 'blue', '#2E86AB') | |
| title | No | Chart title string, e.g., 'Squares' | Line Chart |
| x_data | Yes | X-axis data points, e.g., [1, 2, 3, 4] | |
| y_data | Yes | Y-axis data points, e.g., [1, 4, 9, 16] | |
| x_label | No | X-axis label, e.g., 'Time' | X |
| y_label | No | Y-axis label, e.g., 'Distance' | Y |
| show_grid | No | Whether to display grid lines |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, making the tool's safe nature clear. The description adds the practical requirement 'requires matplotlib' and the note about the alternative tool, which is helpful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two short paragraphs plus examples. Information is well front-loaded: purpose first, then usage note, then examples. Could potentially be slightly more concise by removing 'Note:' prefix, 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?
Given 7 parameters and no output schema, the description adequately covers what the tool does and when to use it. However, it does not mention what the tool returns (e.g., image path, display action), which would be useful for an agent to know how to use the result. Sibling tools are listed in context, completing the landscape.
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 does not add new semantic information about parameters beyond what the schema provides, but the examples help illustrate typical usage of x_data, y_data, title, etc.
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?
Clearly states 'Create a line chart from data points', specifies tool is for general XY data, and differentiates from plot_financial_line for time-series price data. Includes example usage that reinforces purpose.
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?
Explicitly tells when to use (general XY data) and when not (time-series price data, recommending plot_financial_line). Provides multiple concrete examples demonstrating valid usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plot_scatterScatter PlotBRead-onlyIdempotentInspect
Create a scatter plot from data points (requires matplotlib).
Examples: plot_scatter([1, 2, 3, 4], [1, 4, 9, 16], title="Correlation Study") plot_scatter([1, 2, 3], [2, 4, 5], color='purple', point_size=100)
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Point color (name or hex code, e.g., 'blue', '#2E86AB') | |
| title | No | Chart title string, e.g., 'Correlation Study' | Scatter Plot |
| x_data | Yes | X-axis data points, e.g., [1, 2, 3, 4] | |
| y_data | Yes | Y-axis data points, e.g., [1, 4, 9, 16] | |
| x_label | No | X-axis label, e.g., 'Variable X' | X |
| y_label | No | Y-axis label, e.g., 'Variable Y' | Y |
| point_size | No | Scatter point size in points^2, e.g., 50 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the matplotlib dependency but does not disclose whether the plot is displayed, returned as an object, or saved. For a no-output-schema tool, this gap is moderate.
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 one introductory sentence and two illustrative examples. It front-loads the purpose and is free of 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?
Despite high schema coverage, the tool lacks an output schema and the description does not explain what the tool returns (e.g., displays plot, returns a file path, or base64 image). Sibling tools exist but no comparison is provided, leaving the agent uncertain about output behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with clear descriptions (e.g., color as name/hex, point_size in points^2). The tool description does not add additional semantic value beyond the schema, so the baseline 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 'Create a scatter plot from data points (requires matplotlib)', which specifies the verb, resource, and dependency. However, it does not explicitly differentiate from sibling plot tools like plot_line_chart or plot_histogram, relying on the name 'scatter' to imply 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?
No guidance is provided on when to use this tool versus alternatives (e.g., for showing correlation versus trends) or when not to use it. The description lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workspace_loadLoad VariableARead-onlyIdempotentInspect
Load previously saved calculation result from workspace.
Examples: load_variable("portfolio_return") # Returns saved calculation load_variable("circle_area") # Access across sessions
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the variable to load from workspace, e.g., 'circle_area' |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| error | No | |
| topic | No | |
| action | Yes | |
| result | No | |
| success | Yes | |
| timestamp | No | |
| difficulty | No | |
| expression | No | |
| session_id | No | |
| available_variables | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. Description adds no further behavioral details like error handling or permissions, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences and code examples. No wasted 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 output schema exists, description is sufficient for a simple load operation. Covers core functionality.
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%. Examples in description provide real-world usage context for the 'name' parameter, adding value beyond the schema description.
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?
Description clearly states it loads previously saved calculation results from workspace, distinguishing it from sibling tools like workspace_save and calc tools. Examples reinforce the purpose.
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?
Description implies usage after workspace_save, but lacks explicit when-to-use or when-not-to-use guidance. Examples provide context but no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workspace_saveSave Calculation to WorkspaceAInspect
Save calculation to persistent workspace (survives restarts).
Examples: save_calculation("portfolio_return", "10000 * 1.07^5", 14025.52) save_calculation("circle_area", "pi * 5^2", 78.54)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Variable name for the saved calculation. Used to retrieve it later. Example: 'circle_area' | |
| result | Yes | Numeric result of evaluating the expression, e.g., 78.54 | |
| expression | Yes | The mathematical expression that was evaluated. Example: 'pi * r**2' |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| topic | Yes | |
| action | No | |
| is_new | Yes | |
| result | Yes | |
| success | Yes | |
| difficulty | Yes | |
| expression | Yes | |
| session_id | No | |
| total_variables | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutating) and idempotentHint=false. The description adds value by stating persistence across restarts, which is behavioral context beyond the annotations. No contradictions.
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 clear sentence for purpose followed by two relevant examples. Every part earns its place, with no wasted 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 presence of an output schema (context signals: true) and complete parameter documentation, the description adequately supports correct invocation. It could mention linking to workspace_load, but the examples and schema suffice.
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 all three parameters. The description provides concrete examples that demonstrate parameter usage, adding meaning beyond the 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 the tool saves a calculation to a persistent workspace that survives restarts, using a specific verb ('Save calculation') and resource ('Workspace'). It effectively distinguishes itself from siblings like workspace_load by focusing on persistence.
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 no explicit guidance on when to use this tool versus alternatives like workspace_load. It implies usage through context but lacks explicit when-to-use or when-not-to instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!