UpMath MCP Server

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation4/5
Most tools have distinct purposes, such as render_equation for single equations, render_batch for multiple equations, and scan_document_math for analysis. However, check_syntax and validate_equations overlap slightly, as both involve syntax validation, which could cause minor confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as render_equation, scan_document_math, and list_diagram_templates. This predictability makes it easy for agents to understand and select tools.
Tool Count4/5
With 16 tools, the count is slightly high but reasonable for a comprehensive math rendering and document processing server. It covers various aspects like rendering, validation, and analysis without feeling excessively bloated.
Completeness5/5
The toolset provides complete coverage for mathematical document processing, including rendering (equations, diagrams, papers), validation (syntax and equations), analysis (scanning and notation), and utilities (templates and caching). No obvious gaps exist for the domain.
Average 3.6/5 across 15 of 16 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool renders and saves files, but doesn't cover critical aspects like error handling, performance (e.g., rate limits), file overwriting behavior, or output details. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and every word contributes to understanding the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch rendering tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, file naming conventions, or output format details, leaving the agent with incomplete context for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide examples). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('render multiple LaTeX equations at once') and outcome ('saving each to a file'), which is specific and distinguishes it from single-equation tools like render_equation. However, it doesn't explicitly differentiate from similar batch tools like render_batch_cached, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like render_batch_cached, render_equation, or render_equation_sheet. It mentions the basic function but lacks context about scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions rendering to HTML with embedded SVG equations, which hints at output format, but doesn't cover critical aspects like whether this is a read-only operation, potential side effects (e.g., file creation via 'saveTo'), performance considerations, or error handling. For a tool with parameters and no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and output, with no wasted words. It directly communicates the tool's function without unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return value (e.g., HTML string or file path), error conditions, or how the 'saveTo' parameter affects behavior (e.g., whether it saves to disk or returns a file reference). For a rendering tool with potential side effects, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'markdown' as input content and 'saveTo' as an optional file path. The description adds minimal value beyond the schema, only implying that LaTeX equations should be in $$...$$ format, which is somewhat redundant with the schema's description. Baseline 3 is appropriate since the schema does the heavy lifting.
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 'Render' and the resource 'markdown containing $$...$$ LaTeX to HTML with embedded SVG equations', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'render_equation' or 'render_paper', which likely handle similar content but with different scopes or outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'render_equation' for standalone equations or 'render_paper' for full documents. It implies usage for markdown with LaTeX equations but lacks explicit when/when-not instructions or prerequisites, leaving the agent to infer context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'attempting to render' as the validation method, but doesn't describe what happens during rendering (e.g., whether it's a dry run, what errors are returned, performance characteristics, or rate limits). For a validation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every element serving a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validation through rendering), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It explains what the tool does but doesn't cover behavioral aspects like error handling, output format, or performance considerations that would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'latex' documented as 'LaTeX to validate.' The description adds no additional parameter semantics beyond what the schema already provides. According to the rules, when schema coverage is high (>80%), the baseline is 3 even without parameter details in the description.
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: 'Check if LaTeX syntax is valid by attempting to render it.' This specifies the verb ('check'), resource ('LaTeX syntax'), and method ('attempting to render'). However, it doesn't explicitly differentiate from sibling tools like 'validate_equations' or 'scan_document_math', which appear related to validation tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'validate_equations' and 'scan_document_math' that might overlap in functionality, there's no indication of when this specific syntax check is appropriate, what prerequisites exist, or when other tools should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions rendering with custom parameters but doesn't disclose behavioral traits like whether it's read-only/destructive, performance characteristics, error handling, or output specifics. The description is functional but lacks transparency about how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and provides a useful list of templates. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters that performs rendering. It doesn't explain what the output looks like (e.g., file saved, content returned), error conditions, or behavioral constraints. For a tool that likely generates files or images, this leaves significant gaps.
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%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by listing template examples, but doesn't provide additional semantic context like parameter interactions or usage examples. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Render' and resource 'pre-built TikZ diagram template with custom parameters', and lists specific template examples. It distinguishes from siblings like 'render_tikz' (general rendering) by specifying template-based rendering, though not explicitly contrasting with all alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by listing available templates, suggesting when this tool is appropriate for those diagram types. However, it lacks explicit guidance on when to use this vs. alternatives like 'render_tikz' or 'render_batch', and no prerequisites or exclusions 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 of behavioral disclosure. It mentions the tool renders equations into an HTML page and saves it to a file, but doesn't describe what happens if the file path is invalid, whether it overwrites existing files, if there are rate limits, or what the output looks like (e.g., HTML structure). For a tool with file system interaction and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the purpose and another providing usage context. It's front-loaded with the core functionality, and every sentence adds value without redundancy. However, it could be slightly more structured by explicitly separating purpose from guidelines.
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 moderate complexity (rendering equations to HTML with file saving), no annotations, and no output schema, the description is incomplete. It covers the basic purpose and usage but lacks details on behavioral aspects like error handling, file overwriting, or output format. The schema handles parameters well, but the description should compensate for missing annotations and output information.
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%, so the schema already documents all parameters (title, equations, saveTo). The description adds minimal value by implying the tool handles 'collections' of equations, which aligns with the 'equations' array parameter, but doesn't provide additional semantics beyond what the schema specifies. Baseline 3 is appropriate when the schema does the heavy lifting.
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: 'Render a collection of named equations into a single reference sheet HTML page.' It specifies the verb (render), resource (equations), and output format (HTML page). However, it doesn't explicitly differentiate from sibling tools like 'render_equation' (singular) or 'render_markdown_with_math', which might have overlapping functionality.
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 provides some usage context with 'Useful for creating equation cheat sheets or appendix summaries,' which implies when this tool is appropriate. However, it doesn't explicitly state when to use alternatives like 'render_equation' (for single equations) or 'render_markdown_with_math' (for markdown content), nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Render') and output formats but lacks critical details: whether rendering is resource-intensive, has rate limits, requires specific permissions, or how errors are handled. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Render a TikZ diagram to SVG or PNG') and adds supporting details without waste. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with full schema coverage but no output schema or annotations, the description is minimally adequate. It covers the what (rendering TikZ) but lacks context on behavioral traits, error handling, or performance considerations, which are important for a rendering tool with potential complexity.
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%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as examples of TikZ code structure or package usage nuances. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Render' and the resource 'TikZ diagram', specifying the output formats (SVG or PNG) and supported libraries (tikz, pgfplots, circuitikz, tikz-3dplot). It distinguishes from siblings like render_equation or render_markdown_with_math by focusing on TikZ diagrams specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. It mentions supported libraries but doesn't compare to siblings like render_diagram_template or render_batch, leaving the agent to infer usage context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool's function but does not disclose behavioral traits such as whether it modifies the input file, requires specific file permissions, handles errors, or has performance considerations. The description is functional but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core functionality and followed by a practical use case. Every sentence earns its place without redundancy or unnecessary elaboration, making it efficient and easy to understand.
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 no annotations and no output schema, the description adequately covers the tool's purpose but lacks details on behavior, error handling, or output format specifics. It is complete enough for basic understanding but insufficient for full operational guidance without relying on the schema for parameters.
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%, so the schema already documents all parameters thoroughly. The description does not add meaning beyond the schema, as it does not explain parameter interactions, default behaviors, or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Extract all mathematical notation from a markdown file and generate a formatted notation table') and distinguishes it from siblings by focusing on notation extraction rather than rendering, validation, or other document processing tasks. It explicitly mentions the output components (symbol, meaning, first appearance) and practical use case ('creating a Notation section in a paper').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Useful for creating a Notation section in a paper') but does not explicitly state when to use this tool versus alternatives like 'scan_document_math' or 'validate_equations'. It provides a general purpose but lacks specific guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool generates a URL but doesn't disclose behavioral traits like whether it's a read-only operation, if it requires authentication, rate limits, or what happens with invalid LaTeX. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get the UpMath URL for a LaTeX expression') and adds clarifying context ('for embedding in HTML/markdown'). Every word earns its place with zero waste.
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 no annotations and no output schema, the description adequately covers the basic purpose but lacks details on behavior, error handling, or return values. For a simple tool with 2 parameters and 100% schema coverage, it's minimally viable but could benefit from more context on operational 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?
Schema description coverage is 100%, so the schema fully documents both parameters ('latex' as LaTeX expression, 'format' with enum values). The description doesn't add any parameter-specific details beyond what the schema provides, such as LaTeX syntax requirements or format implications, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('UpMath URL'), and the specific purpose ('for a LaTeX expression for embedding in HTML/markdown'). It distinguishes from siblings like 'render_equation' (which might return an image) by focusing on URL generation for embedding.
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 when needing a URL for embedding LaTeX in web content, but doesn't explicitly state when to use this vs. alternatives like 'render_equation' (which might return rendered content directly) or 'render_markdown_with_math' (which handles broader markup). No explicit exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool as a scanning operation that returns analytical outputs, implying it's a read-only, non-destructive process, but does not detail error handling, performance characteristics, or any side effects. This is adequate for a basic read tool but lacks depth in 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 front-loaded with the core action and outputs in the first sentence, followed by a context sentence. It is efficient with two sentences that directly convey purpose and use case, though the second sentence could be slightly more concise by integrating the context more tightly.
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 moderate complexity (scanning and analysis), no annotations, no output schema, and 100% schema coverage, the description is minimally complete. It covers what the tool does and its intended use but lacks details on output format, error cases, or integration with sibling tools, leaving some gaps for an AI agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('inputFile' and 'outputReport') clearly documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as file format expectations or report structure, so it meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Scan a markdown file for all LaTeX math') and resource ('markdown file'), distinguishing it from sibling tools like 'validate_equations' or 'render_markdown_with_math' by focusing on analysis rather than validation or rendering. It explicitly lists the outputs (equation inventory, symbol frequency table, etc.), making the purpose distinct and comprehensive.
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 'maintaining consistency in scientific papers,' suggesting it's for quality control in academic writing. However, it lacks explicit guidance on when to use this tool versus alternatives like 'validate_equations' or 'render_markdown_with_math,' and does not specify prerequisites or exclusions, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the service provider (UpMath) and the two behavioral outcomes (returns SVG markup or saves to file), which is useful. However, it doesn't mention rate limits, authentication needs, error conditions, or whether the operation is idempotent - significant gaps for a tool with external dependencies.
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 zero waste. The first sentence states the core functionality, and the second explains the two possible outcomes. Every word earns its place, and the most important 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?
For a tool with 3 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers the basic purpose and outcomes but lacks information about return values (beyond 'SVG markup'), error handling, performance characteristics, or integration details with UpMath service.
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 the schema already documents all parameters well. The description adds value by clarifying the relationship between format and saveTo - that format determines output type while saveTo specifies file storage. This semantic context goes beyond the schema's individual 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 specific action ('Render a LaTeX equation'), the resource ('to SVG or PNG'), and the method ('via UpMath'). It distinguishes from siblings by focusing on single equation rendering rather than batch operations, diagrams, or other document types mentioned in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'LaTeX equation' and output formats, but doesn't explicitly state when to use this versus alternatives like render_batch, render_equation_sheet, or render_markdown_with_math. No explicit when-not-to-use guidance or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: rendering markdown to HTML, using KaTeX for standard math and UpMath API for TikZ/special packages, and handling various markdown elements. However, it lacks details on performance implications (e.g., speed differences), error handling, or output specifics, leaving some behavioral aspects 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 appropriately sized and front-loaded, starting with the core purpose and key features (LaTeX rendering, KaTeX/UpMath usage). Every sentence adds value without redundancy, efficiently covering the tool's functionality in a compact format with zero waste.
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 complexity of rendering markdown with LaTeX math, no annotations, and no output schema, the description is moderately complete. It covers the main purpose and behavioral traits but lacks details on output format, error cases, or dependencies, which could be important for an AI agent to use it correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by implying the tool processes markdown files with LaTeX, but it does not provide additional semantics for parameters like inputFile or outputFile. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Render a full markdown paper') and resource ('to a publication-ready HTML file'), distinguishing it from siblings like render_equation or render_markdown_with_math by emphasizing full paper rendering with LaTeX math support. It explicitly mentions handling various markdown elements (headings, bold, lists, etc.), which further clarifies its comprehensive scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (rendering markdown papers with LaTeX math to HTML) and implies alternatives by noting the fallback to UpMath API for special cases, but it does not explicitly name sibling tools like render_markdown_with_math or specify when to choose this over them. It offers some guidance on math rendering options but lacks explicit when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool creates an HTML file (implied by 'producing an HTML comparison page' and 'saveTo' parameter), but doesn't mention permissions needed, rate limits, error conditions, or what happens if the file already exists. The behavioral context is minimal but not contradictory.
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 with zero waste. The first sentence states purpose and output, the second provides key usage guidance. Every word earns its place and the information is front-loaded appropriately.
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 tool with 4 parameters, no annotations, and no output schema, the description is adequate but minimal. It covers the core purpose and basic usage but lacks details about behavioral traits, error handling, or output format beyond 'HTML comparison page'. The schema carries most of the parameter documentation burden.
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%, so the schema already documents all parameters thoroughly. The description adds some context about the {PARAM} placeholder usage and the exploration purpose, but doesn't provide additional syntax, format, or constraint details beyond what's in the 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?
The description clearly states the specific action ('Render a parameterized equation across a grid of values') and the output ('producing an HTML comparison page'). It distinguishes from siblings by focusing on parameter grid exploration rather than individual rendering or validation tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context ('Useful for exploring how changing coefficients affects formulas') that indicates when to use this tool. However, it doesn't explicitly mention when not to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior by stating it returns an HTML page and can save to a file path, but doesn't mention potential limitations like rendering time, error handling for invalid LaTeX, or whether the HTML is self-contained. It adequately describes the core behavior but lacks depth on operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that efficiently convey purpose and output. Every word earns its place—no redundancy or fluff. It's front-loaded with the core functionality followed by the return type.
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 moderate complexity (comparative rendering with file output), no annotations, and no output schema, the description is reasonably complete. It covers what the tool does and the output format, but could benefit from mentioning error cases or the structure of the returned HTML. It's adequate but not exhaustive.
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%, so the schema already fully documents all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify LaTeX format requirements or file path specifics). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('render two versions side by side for visual comparison'), the resource ('LaTeX equation'), and the output format ('HTML page'). It distinguishes itself from sibling tools like 'render_equation' (single equation rendering) and 'render_equation_sheet' (multiple equations) by focusing specifically on comparative visualization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests usage for comparing original vs. modified LaTeX equations, which provides clear context. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the siblings (e.g., 'render_equation' for single equations, 'validate_equations' for validation without rendering).
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 states the tool lists templates with descriptions, which implies a read-only, non-destructive operation, but does not disclose behavioral traits such as pagination, rate limits, authentication needs, or output format details. The description adds basic context but lacks depth for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all available TikZ diagram templates') and adds value by specifying 'with descriptions'. There is zero waste, making it appropriately sized and structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is complete enough for basic understanding. However, it lacks details on output format (e.g., structure of the list, whether it includes metadata) and behavioral aspects like performance or constraints, which could enhance completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there is no need for parameter details in the description. The baseline for 0 parameters is 4, as the description appropriately focuses on the tool's purpose without redundant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('List') and resource ('all available TikZ diagram templates with descriptions'), distinguishing it from siblings like 'render_diagram_template' or 'render_tikz' which focus on rendering rather than listing. It precisely defines the scope as enumerating templates with their 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 implies usage when needing to browse or select from available templates, but does not explicitly state when to use this tool versus alternatives like 'render_diagram_template' for creating diagrams or other rendering tools. It provides clear context for template discovery but lacks explicit exclusions or named alternatives.
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 provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: caching behavior ('skips re-rendering unchanged equations'), performance benefit ('Much faster'), and session persistence ('Cache persists within the MCP session'). It doesn't cover aspects like error handling or rate limits, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: three sentences with zero waste. The first sentence states the core purpose, the second explains the benefit, and the third clarifies cache scope—each earning its place by adding distinct value.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage context, and behavioral traits like caching. However, it lacks details on return values (e.g., what the tool outputs) and error cases, which are notable gaps for a rendering 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 description coverage is 67% (2 of 3 parameters have descriptions). The description adds no specific parameter semantics beyond what the schema provides—it doesn't explain 'equations', 'format', or 'outputDir' further. Since coverage is moderate (>50%), the baseline score of 3 is appropriate, as the schema does most of the work without description compensation.
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: 'Render multiple equations with caching — skips re-rendering unchanged equations.' It specifies the verb ('render'), resource ('multiple equations'), and key behavior ('with caching'), distinguishing it from siblings like 'render_batch' (which likely lacks caching) and 'render_equation' (which renders single equations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Much faster for iterative editing.' This implies it's optimal for scenarios where equations are edited incrementally. However, it doesn't explicitly state when not to use it or name alternatives (e.g., 'render_batch' for non-iterative cases), which prevents a perfect score.
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 provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it validates equations, checks LaTeX syntax via UpMath, reports render errors, flags issues like unmatched braces, and notes it's slower than scan_document_math. However, it lacks details on error formats, rate limits, or authentication needs, leaving some behavioral aspects 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 front-loaded with the core purpose in the first clause, followed by specific checks and a comparative guideline. Every sentence earns its place by adding value: the first defines the tool, the second details validation aspects, and the third provides usage context. It's efficiently structured with zero waste.
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 no annotations, 2 parameters with full schema coverage, no output schema, and moderate complexity, the description is largely complete. It covers purpose, behavior, and usage guidelines effectively. However, without an output schema, it doesn't explain return values (e.g., error report format), leaving a minor gap in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('inputFile' as path to markdown file, 'maxEquations' with default and usage note). The description adds no additional parameter semantics beyond what the schema provides, such as file format details or equation validation specifics. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('validate all equations'), resource ('markdown file'), and scope ('check LaTeX syntax via UpMath, report render errors, flag potential issues'). It explicitly distinguishes from sibling 'scan_document_math' by noting it's slower but verifies renderability, making the purpose unambiguous and 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?
The description provides explicit guidance on when to use this tool vs. alternatives: 'Slower than scan_document_math but verifies renderability.' This directly compares it to a sibling tool, helping the agent choose based on speed vs. thoroughness. No exclusions are stated, but the comparison suffices for strong guidance.
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:

[![upmath-mcp MCP server](https://glama.ai/mcp/servers/danielsimonjr/upmath-mcp/badges/card.svg)](https://glama.ai/mcp/servers/danielsimonjr/upmath-mcp)

Score Badge

Copy to your README.md:

[![upmath-mcp MCP server](https://glama.ai/mcp/servers/danielsimonjr/upmath-mcp/badges/score.svg)](https://glama.ai/mcp/servers/danielsimonjr/upmath-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/danielsimonjr/upmath-mcp'

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