axiomatic-mcp

Official

by Axiomatic-AI

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.17
Disambiguation2/5
Multiple 'report_feedback' tools (7 total) across different subsystems all perform the same function, creating ambiguity about which to call after a given tool. 'generate_code' and 'execute_code' tools also overlap across subsystems (AxArgmin vs AxModelFitterV2). AxModelFitter and AxModelFitterV2 have overlapping purposes.
Naming Consistency5/5
All tools follow a consistent 'Ax[Subsystem]_[action]' pattern with snake_case verbs (e.g., AxModelFitter_fit_model, AxPlotToData_extract_numerical_series). No mixing of conventions across the entire tool set.
Tool Count3/5
23 tools is on the high side for a coherent server. The count is inflated by 7 nearly identical 'report_feedback' tools and duplicate 'execute_code' tools, suggesting poor scoping. However, the core capabilities (fitting, plotting, equation, document) could justify around 15-20 tools.
Completeness3/5
Model fitting has comprehensive diagnostics (R², AIC, cross-validation, covariance), but there are notable gaps: no data preprocessing, no visualization, and the two fitting workflows (direct fit via AxModelFitter vs code generation via AxModelFitterV2) are redundant. Equation and document tools are sparse.
Average 3.8/5 across 23 of 23 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 4 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on June 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions validation and corrections without detailing side effects, permissions, or whether it auto-corrects. The behavior of providing corrections is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, but the first includes a meta-instruction ('Ask the agent...') which is redundant. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema. The description fails to specify what the tool returns (e.g., boolean, suggestions). This is a significant gap for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as description does not improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates equations and corrects errors, using a specific verb and resource. However, it does not differentiate from sibling tools like 'find_functional_form' or 'report_feedback'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'AxEquationExplorer_find_functional_form'). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions file type support but does not indicate whether the operation is read-only, destructive, or what the output includes. Lacks details on side effects or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded. Every sentence adds value (purpose + supported types). No wasted words, but could be more informative in the same space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description should explain what the annotation result is. It does not mention return values or behavior. For a 2-param tool with no nested objects, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so basic param info is already present. The description adds context about supported file types beyond the schema but does not elaborate on the 'query' parameter or file_path format beyond what is already defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'annotate' and the resource 'file', and lists supported file types (PDF, PNG, JPEG, MD, TXT). It distinguishes from sibling tools like AxDocumentParser_parse_pdf_to_md which converts formats rather than analyzing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like the parser or analysis tools. The supported file types hint at scope but no context on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It states the tool will derive an expression but does not describe what it returns (no output schema), any side effects, authentication needs, or error conditions. The behavior is minimally explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. It is concise and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It does not explain what 'derive' means operationally, what the output looks like, or how the document is processed. For a tool that likely generates an expression, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds a hint about providing a description of the expression, but it does not add significant meaning beyond the schema for the 'task' and 'document' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'derive' and specifies the resource as 'expression of your interest' from source documents, which aligns with the tool name 'find_functional_form'. It is clear what the tool does, but it does not explicitly differentiate from sibling tools; however, the context signals show its uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context that would help an agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'precise numerical data points' but does not disclose limitations such as accuracy, supported plot types (only line/scatter implied), behavior with noisy data, or output format. The description is too brief to adequately inform an agent about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Analyzes' and resource. It is concise with no wasted words, but could benefit from more structure if expanded. For its length, it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not explain return values, error handling, or limitations beyond the schema. For a tool of moderate complexity (2 parameters), more context is needed to understand what the tool produces and how it handles edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The tool description adds no extra meaning beyond what the schema already provides for plot_path and max_number_points_per_series. No additional context is given for parameter interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes images of line and scatter plots to extract numerical data points from all series. The verb 'analyzes' and resource 'images of line and scatter plots' are specific, and the purpose distinguishes it from siblings like AxPlotToData_split_multi_plot which splits multi-plot images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extracting data from all series in a plot but does not provide explicit guidance on when to use this tool versus alternatives like split_multi_plot or when not to use it. No exclusions or context for selection are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as output format, side effects (e.g., temporary file creation), or whether the operation is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key information. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description explains input and operation but omits the output format (e.g., saved paths or returned data). This is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the plot_path parameter well-documented. The description adds no additional meaning beyond the schema, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'splits' and the resource 'image of a plot with multiple subplots' into 'individual subplots'. It distinguishes from siblings like AxPlotToData_extract_numerical_series and AxPlotToData_report_feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that splitting should precede extraction nor 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It discloses output file naming and image directory, but does not state whether the original file is preserved, specify error handling, or detail the conversion process beyond 'advanced OCR'. Some behavioral aspects remain unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences, front-loading the purpose and then detailing output behavior. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers basic usage but omits key details like return value (does it return file path or content?), supported PDF types, and error scenarios. This leaves some ambiguity for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage and a single straightforward parameter (file_path), the description adds no additional meaning beyond the schema's 'absolute path to the PDF file to analyze'. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts PDF to markdown using OCR, specifying the verb (convert), resource (PDF to markdown), and technology (OCR). It effectively distinguishes itself from sibling tools like AxDocumentAnnotator_annotate_file or AxDocumentParser_report_feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there prerequisites, limitations, or exclusions mentioned. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what the tool does but does not disclose side effects, auth needs, or safety. Since the tool is a read-only reporting action, the lack of detail is acceptable but not outstanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and uses a list format for clarity. Every sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple feedback tool with no output schema, the description covers when to call, what to include, and the required parameters. It is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats the parameter names and purposes, adding little beyond the schema descriptions. No additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Summarize the tool call you just executed' and specifies that it should be called after any other tool. This makes the purpose clear, though it does not explicitly differentiate from other report_feedback sibling tools beyond the naming prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Always call this after using any other tool,' which provides clear usage context. However, it does not mention when not to use it or how to choose among multiple report_feedback tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does not disclose behavioral traits such as state modification, safety, or error behavior. The purpose is clear but lacks transparency beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the core purpose. The inline bullet list of parameters is useful but could be streamlined to avoid redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple feedback tool with 100% parameter coverage and no output schema, the description provides sufficient context. It explains the tool's role and expected inputs, though it could mention safety or idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. The description adds some context (e.g., 'feedback can be a short summary'), but largely mirrors schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is for summarizing the just-executed tool call, using the verb 'Summarize' and specifying the resource ('tool call'). It distinguishes itself from sibling tools as a feedback/reporting tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Always call this after using any other tool.' This clearly indicates when to use it, though it does not discuss when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must handle behavioral disclosure. It correctly states the tool returns executable code and an explanation, and mandates separate execution. However, it does not mention side effects, permissions, or safety characteristics (e.g., read-only nature).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences covering purpose, usage, and dependency on another tool. No redundant information; every sentence adds value. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input parameter and the follow-up action (execute_code). It lacks details about return format, error handling, or example usage, but given the simple single-parameter input and no output schema, it is mostly sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The description adds that the parameter is a natural language description of the model, data, and fitting goal, which largely echoes the schema description. It provides no additional syntax or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates Python code to fit a parametric model using a specific JAX library, with a specific verb ('generate') and resource ('code'). It distinguishes from siblings like AxModelFitter_fit_model (which actually fits the model) and AxArgmin_generate_code (for argmin).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the user to describe the model, data, and fitting goal, and mentions that the code must be executed separately with execute_code. However, it does not explicitly contrast with alternatives (e.g., when to use this vs. AxModelFitter_fit_model), relying on implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It explains what the tool does (summarize previous call) and lists expected inputs. It does not cover side effects or error conditions, but for a logging/report tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and uses a bullet list for clarity. It is reasonably concise, though the bullet points could be slightly more terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the tool's return value or output. Given that it has no output schema, the description should explain what the tool returns. Also, there is no unique context differentiating it from sibling feedback tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds value by grouping the parameters and providing context (e.g., 'feedback_value: one of positive, negative, neutral'), going beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to summarize the previous tool call. It provides a list of required fields. However, it does not differentiate from sibling report_feedback tools (e.g., AxDocumentParser_report_feedback) which likely have identical descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Always call this after using any other tool,' providing clear when-to-use guidance. It does not explicitly state when not to use or provide alternatives, but the context makes it sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses the sandboxed environment and the necessity of export calls. However, it omits details on timeouts, resource limits, error handling, or side effects (e.g., filesystem access). While adequate for a basic code execution tool, more behavioral context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the tool's purpose, environment, requirement, and typical usage. No extraneous words; critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete but missing key details about output format—how results are returned (e.g., through export only? Are print statements captured?). Without an output schema, this gap hinders full understanding. Also lacks error handling details. Nonetheless, it covers the main functional aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema alone provides 100% coverage with a clear description including the export requirement. The tool description adds no new information beyond restating the export condition, so it adds minimal value over the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute Python code'), the environment ('sandboxed with JAX, diffrax, equinox, ax_core.model_fitter'), and distinguishes from sibling tools by mentioning it is typically used for code produced by generate_code, implying a specific workflow within the AxModelFitterV2 family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by stating the typical use case ('run code produced by generate_code') and flexibility ('accepts hand-written or modified code'). It also specifies a requirement (must call export). However, it lacks explicit comparisons or when-not-to-use advice relative to other execute_code siblings like AxArgmin_execute_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions sandboxing, available libraries, and export requirement, but lacks details on security, resource limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary content. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers key aspects (libraries, export requirement, sandbox). Lacks details on return values and error behavior but is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter. The description reinforces the export requirement but adds no additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes Python code in a sandboxed environment with specific libraries, and distinguishes from sibling tools like generate_code which produces code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions typical use to run code from generate_code but also accepts hand-written code, providing clear context. It lacks explicit when-not-to-use guidance but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses that the tool collects feedback parameters and is a read-only reporting action. Behavior is transparent, though no side effects are discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with bullet points. Front-loads the purpose and immediately states usage. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information about the tool's return value or side effects. Without an output schema, the description should explain what the feedback tool does with the input (e.g., logs, returns confirmation). This is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by listing required fields in a structured list and explaining their purpose. It clarifies the expected usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarizes a tool call after using any other tool. The name 'report_feedback' is explicit. However, multiple siblings share the same suffix (e.g., AxEquationExplorer_report_feedback), so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Always call this after using any other tool,' providing clear usage context. No mention of when not to use or alternatives, but the directive is strong and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: uses numerical optimization, returns optimized parameters, R², execution time, and result files. Mentions JIT compilation and optimizer options. No annotations exist, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (description, required inputs, example, requirements, returns) and front-loaded purpose. Some redundancy (e.g., 'All data MUST be provided via files' repeated), but overall efficient for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects: data input, parameter mapping, function requirements, and returns. Missing details on error handling or multiple output scenarios, but schema provides parameter details. Adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond the schema by grouping parameters into required inputs, providing data mapping examples, explaining JAX function requirements, and clarifying unit usage. Schema coverage is 100%, so high baseline, but description enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool fits custom JAX mathematical models to experimental data using files. Verb 'fit' and resource 'custom JAX model' are specific, and the description distinguishes it from siblings like cross_validate_model or compare_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit required inputs and emphasizes file-based data input, but does not discuss when to use this tool versus other fitting tools (e.g., cross_validation) 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it 'Returns ready-to-use templates' with specific contents, implying a read-only operation. However, with no annotations provided, it does not explicitly disclose the absence of side effects, authentication needs, or rate limits. The description could be more transparent about the tool's safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using 7 lines to convey purpose, contents, and usage instruction. It front-loads the main action ('Get complete working examples') and lists features concisely. Every sentence adds value, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no parameters, the description adequately explains the return value (templates with specific components) and provides examples of included models. It is complete for a simple retrieval tool, covering what the agent needs to know to use the templates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter information. With no parameters, a baseline score of 4 is appropriate. The description covers the tool's purpose without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get complete working examples for model fitting with the AxModelFitter.' It lists specific components of the templates (JAX function syntax, pint units, parameter bounds, file-based examples). This distinguishes it from sibling tools like fit_model, cross_validate_model, etc., which perform fitting or evaluation rather than providing examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Use these as starting points - copy the structure and modify for your specific model.' This indicates when to use the tool. However, it does not provide explicit guidance on when not to use it or alternatives, though the sibling list offers context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully owns transparency. It discloses that the tool returns executable code and an explanation, and notes that execution is separate. Could mention no side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded and to the point. Every sentence provides value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (code generation for multiple problem types) and lack of output schema, the description covers key points: purpose, return value, and relationship to sibling. Could elaborate on input format for problem_description, but schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds no additional parameter-level details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates Python code for numerical problems using the argmin library, lists supported problem types explicitly, and distinguishes from sibling tools like execute_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions that code must be executed separately using execute_code. Implicitly distinguishes from other code generators via argmin focus, but could add more explicit when-not-to-use pointers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains parameter meanings and R² interpretation but does not explicitly disclose side effects, permissions, or whether the tool is read-only. This is adequate but not outstanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (SIMPLE USAGE, WHAT R² MEANS, WORKS WITH). It is concise, front-loaded with the purpose, and every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 params, one nested object), the description explains the inputs and output interpretation. However, it lacks explicit description of the return value format, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by providing 'SIMPLE USAGE' examples and explaining 'WHAT R² MEANS,' going beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Calculate R-squared to measure how well your model fits the data.' It uses a specific verb (Calculate) and resource (R-squared), and is distinct from sibling tools like information criteria or cross-validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by stating 'Use this to quickly assess if your optimization produced a good fit,' but does not explicitly mention when not to use it or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses use of two estimators and return values, but does not mention side effects, computational cost, or assumptions like numerical stability. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three brief sections (main verb, method details, required/returns). Each sentence serves a purpose with no redundancy. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, nested objects, and no output schema, description covers the main purpose, required items, return types, and estimator methods. Could add example usage or explain impact of cost_function_type, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by stating default behavior for 'variance' parameter (estimated from loss if None) and summarizing return structure (covariance matrices, standard errors, correlation matrix).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool computes parameter covariance matrices for fitted model parameters. Specifies two methods (robust Huber-White, classical inverse Hessian) and explicitly says to use after fit_model, distinguishing it from the fitting step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use after fit_model' and lists required items (fitted parameters, model definition, etc.). Provides clear prerequisites but does not explicitly exclude alternatives or mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool uses AIC/BIC for ranking and returns ranked models with statistical evidence (Akaike weights). It also states 'Lower AIC/BIC = better model.' Since no annotations are provided, the description carries full burden and does so adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is logically structured with sections USE CASE, REQUIRED INPUTS, EXAMPLE MODELS INPUT, and RETURNS. It is front-loaded and efficient. Minor inefficiencies like 'REQUIRED INPUTS' and 'RETURNS' could be integrated, but overall it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters (3 required), complex nested objects, and no output schema, the description covers the main purpose and key inputs. It explains the model list structure and output behavior. Some parameters like n_obs and df_effective are not explained in the description but are covered in the schema. The description is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The tool description adds value with an example models input, clarification that sigma is required for mse and None for mae, and explanation of data_file and output_data requirements. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Compare multiple models to find the best one using statistical criteria.' It specifies the verb (compare), resource (models), and outcome (best one). This distinguishes it from sibling tools like fit_model or cross_validate_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A use case is explicitly given: 'You have several competing models... This tool tells you which model is statistically best.' Required inputs are listed and an example is provided. However, it does not mention when not to use this tool or alternatives among siblings like calculate_information_criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It lists the required and optional parameters but does not disclose potential side effects (e.g., whether feedback is stored or affects future behavior). The description is straightforward but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the purpose, followed by a bullet list of parameters. Every sentence is necessary and adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a reporting meta-tool), the description covers all necessary information: what it does, when to use it, what parameters to include, and how to provide feedback. It is complete without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by listing each parameter with an explanation (e.g., 'previous_called_tool_name: the name of the previous tool called'). It also clarifies defaults for feedback_value and the optional nature of feedback, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Summarize the tool call you just executed. Always call this after using any other tool.' It specifies the verb 'summarize' and the resource 'tool call', differentiating it from sibling tools that perform distinct tasks such as fitting models or parsing documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Always call this after using any other tool.' This makes the usage context clear. It does not mention when not to use it or suggest alternatives, but given the nature of a feedback reporting tool, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses validation types, interpretation of R² values, and that it uses the same inputs as fit_model. It doesn't explicitly state that the tool does not modify the model, but the description implies a read-only evaluation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (REQUIRED INPUTS, VALIDATION TYPES, TYPICAL USAGE, INTERPRETATION). It is concise, front-loads the purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 20 parameters, 8 required, and no output schema, the description provides a good overview of usage and interpretation. It covers validation strategies and typical steps. It could include more on error handling or edge cases, but the description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 20 parameters have descriptions). The description adds significant value by grouping parameters and explaining their relationship to fit_model, typical defaults (e.g., validation_strategy='kfold', n_splits=5), and how to use custom_splits. This goes beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test how well your model generalizes to new data using cross-validation.' It specifies the verb (test/cross-validate) and resource (model generalization), and distinguishes it from siblings like fit_model by focusing on validation rather than fitting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance, including required inputs (same as fit_model), typical usage steps (use same parameters, set validation_strategy='kfold', n_splits=5), and interpretation of results. It could benefit from stating when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers behavior: calculates AIC, BIC, AICc, requires specific parameters, and explains sigma parameter usage with example. Lacks disclosure of error handling or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for required inputs, when to use, sigma parameter, and returns. Each sentence serves a purpose, no redundancy, efficient use of text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and key parameters but could elaborate on return interpretation beyond 'lower is better' and handling of optional parameters like n_scale_params and aicc_include_scale. Adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value by explaining sigma requirement in detail, providing examples, and clarifying n_obs inference. Goes well beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it calculates AIC and BIC for model selection, with specific verb 'calculate' and resource 'information criteria'. It distinguishes from siblings like cross_validate_model and compare_models by focusing on information criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a 'WHEN TO USE' section guiding comparison of model architectures and complexity selection. Does not explicitly state when not to use or name alternatives, but provides clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It transparently describes that this tool summarizes a previous tool call, with no destructive or hidden side effects. The behavior is fully disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the main purpose in the first sentence and a clear list of parameters. It is concise at about 5 sentences, but could be slightly tighter by removing redundant parameter descriptions already in schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple feedback tool with no output schema and full parameter coverage, the description completely explains its role, usage, and required inputs. No gaps remain for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds context by explaining the purpose and example values (e.g., feedback_value enum), but does not add significant meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Summarize the tool call you just executed' with a specific verb and resource, clearly indicating its purpose as a feedback/reporting tool. The name includes 'AxPlotToData' which distinguishes it from sibling feedback tools for other agents, though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Always call this after using any other tool,' providing clear when-to-use guidance. It also lists required fields and their expected content, leaving no ambiguity about how to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![ax-mcp MCP server](https://glama.ai/mcp/servers/Axiomatic-AI/ax-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Axiomatic-AI/ax-mcp)

Score Badge

Copy to your README.md:

[![ax-mcp MCP server](https://glama.ai/mcp/servers/Axiomatic-AI/ax-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Axiomatic-AI/ax-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Axiomatic-AI/ax-mcp'

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