Formath MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as tex_extract for parsing TeX, tasks_* for task management, and render_* for documentation generation. However, there is some potential overlap between tasks_autogen_from_entities and tasks_upsert, as both involve task creation, which could cause minor confusion in selection.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with clear verb_noun structures, such as tasks_list, tasks_upsert, render_entities_markdown, and tex_extract. All tools adhere to this convention, making the set predictable and easy to navigate.
Tool Count5/5
With 14 tools, the server is well-scoped for its formalization project management domain. The tools cover essential areas like TeX processing, task management, project scaffolding, and progress tracking, with each tool serving a clear and necessary function.
Completeness4/5
The tool set provides comprehensive coverage for formalization workflows, including extraction, task lifecycle management, and documentation. A minor gap exists in direct entity manipulation tools, such as updating or deleting entities, but agents can work around this using existing tools like tasks_upsert and render_entities_markdown.
Average 3.2/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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, the description carries full burden but only states the action ('append') without disclosing behavioral traits like whether this is a mutation (likely yes, given 'append'), permission requirements, side effects (e.g., if it modifies task status or just logs), rate limits, or response format. It lacks critical context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action. It's appropriately sized for the tool's apparent complexity, though brevity contributes to gaps in other dimensions.
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 3 parameters, no annotations, and an output schema (which reduces need to explain returns), the description is minimally complete but lacks detail on mutation behavior, parameter meanings, and usage context. It's adequate for basic understanding but has clear gaps for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter semantics. It mentions 'task id' and 'state' implicitly but doesn't explain their roles, formats, or constraints (e.g., valid state values, what project_root does). With 3 parameters and low coverage, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Append a state transition record for a task id' specifies the action (append) and resource (state transition record for a task), but it's vague about what 'append' means operationally (e.g., adds to a log vs. updates a field) and doesn't distinguish it from siblings like tasks_upsert or tasks_list. It avoids tautology by not restating the name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as tasks_upsert (which might update task states) or tasks_list (for viewing states). The description implies usage for recording state changes but doesn't specify prerequisites, exclusions, or contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return format ('JSON list') and a behavioral detail ('latest per id'), which adds value. However, it doesn't address important aspects like whether this is a read-only operation, pagination behavior, rate limits, authentication requirements, or what happens with the 'project_root' parameter. The description provides some behavioral context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in a single sentence that front-loads the core purpose. Every element ('List tasks', 'optionally filter by state', 'Returns JSON list (latest per id)') serves a purpose. It could be slightly more structured but achieves conciseness without wasted words.
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 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. The output schema means return values don't need explanation, but the description should better explain parameter usage and behavioral context. It covers basic purpose and return format but leaves parameter semantics and usage guidelines underdeveloped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions filtering by 'state' but doesn't explain what states are available or how filtering works. It completely ignores the 'project_root' parameter. The description adds minimal semantic value beyond what's inferable from parameter names, failing to compensate for the schema's lack of 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 verb ('List') and resource ('tasks'), and mentions optional filtering by state. It distinguishes from some siblings like 'tasks_upsert' (create/update) and 'tasks_transition' (change state), but doesn't explicitly differentiate from 'tasks_pick_next' or 'tasks_autogen_from_entities'. The purpose is specific but sibling differentiation is incomplete.
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 'tasks_pick_next' (which likely selects specific tasks) or 'progress_summary' (which might summarize task states). It mentions optional filtering by state but doesn't explain when filtering is appropriate or what alternatives exist for different query needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states 'Regenerate' which implies a write operation, but doesn't disclose effects (e.g., overwrites existing file, requires specific permissions), response format, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for its purpose, though it could be slightly more informative without losing conciseness.
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 has an output schema (which handles return values), the description's main gap is lack of behavioral transparency and parameter details. For a regeneration tool with no annotations, it's minimally adequate but leaves critical aspects like mutation effects and parameter usage unclear, making it incomplete for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it doesn't mention the 'project_root' parameter at all. The baseline is 3 because the schema covers the parameter structure, but the description adds no value beyond implying a project context, failing to explain parameter meaning or usage.
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 ('Regenerate') and the specific resource ('formath/entities.md from formath/entities.jsonl'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'render_checklist_markdown' or 'tasks_autogen_from_entities', which might involve similar markdown or entity processing, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, only implying usage when entities.md needs regeneration from entities.jsonl. It offers no explicit when-to-use rules, alternatives (e.g., vs. 'tasks_autogen_from_entities'), or prerequisites, leaving the agent to infer context without clear direction.
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 mentions writing to sibling directories, implying a write operation, but doesn't cover critical aspects like permissions needed, error handling, whether it overwrites existing files, or performance characteristics. This leaves the agent with insufficient information about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with every sentence earning its place. The first sentence defines the pipeline, and the second specifies output locations. There's no wasted verbiage, making it efficient for an agent to parse.
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 complexity (processing pipeline with file outputs) and no annotations, the description is incomplete. It covers the high-level flow and output destinations but lacks details on error cases, side effects, or dependencies. The presence of an output schema helps, but more behavioral context is needed for a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds some value by implying 'tex_path' is the input TeX file and 'module_name' influences the output Lean module, but it doesn't explain parameter formats, constraints, or defaults. This partial compensation meets the baseline for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it's an end-to-end pipeline that processes TeX files to generate Formath JSONL and Lean stub modules. It specifies the verb ('formalize') and resources (TeX files), though it doesn't explicitly differentiate from sibling tools like 'tex_extract' or 'workflow_formalize_all', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions output directories but doesn't explain prerequisites, when to choose this over 'tex_extract' or 'workflow_formalize_all', or any constraints. This lack of contextual usage information is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 generating a file but doesn't disclose behavioral traits like whether it overwrites existing files, requires specific permissions, handles errors, or has side effects. For a file-writing tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 has an output schema (which likely describes the generated markdown), the description doesn't need to explain return values. However, for a file-generation tool with no annotations and incomplete parameter semantics, it should provide more context on behavior and usage to be fully 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?
The description adds no information about the single parameter 'project_root'. With 0% schema description coverage and no parameter details in the description, the baseline is 3 since the schema provides the structure but lacks semantic context. The description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and the specific output resource ('formath/checklist.md'), and identifies the input source ('tasks.jsonl (latest per id)'). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'render_entities_markdown' or 'tasks_list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or when not to use it. With sibling tools like 'tasks_list' and 'render_entities_markdown' available, this gap is significant.
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 carries full burden but only states the basic action and return. It doesn't disclose permissions needed, whether this is idempotent, how 'next open tasks' are determined (e.g., priority, creation time), error handling, or side effects beyond the state change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste, front-loading the core action. Every word earns its place by specifying the operation, scope, and return value efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, but an output schema (which handles return values), the description is minimally adequate. It covers the basic purpose and output but lacks parameter semantics and behavioral context needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It mentions 'limit' generally but doesn't explain the 'project_root' parameter at all or provide format/constraints for either parameter beyond what's in the schema (which has minimal 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 action ('Mark next open tasks as in_progress') and resource ('tasks'), with specific scope ('up to limit') and outcome ('Returns transitioned ids'). It distinguishes from siblings like tasks_list (list) and tasks_transition (general transition), but doesn't explicitly name 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 when needing to advance tasks to in_progress state with a limit, but doesn't specify when to use this vs. tasks_transition (which might handle arbitrary transitions) or tasks_autogen_from_entities. No explicit when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format ('compact JSON summary'), which adds some value, but fails to address critical aspects like error handling, performance, or whether the operation is read-only or has side effects. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences that directly state the action and output. Every word earns its place, with no unnecessary information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (extracting from TeX files), no annotations, and an output schema that likely covers return values, the description is minimally adequate. It specifies the action and output format, but lacks details on behavioral traits and parameter semantics, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any semantic details about the single parameter 'tex_path' beyond what the input schema provides (which has 0% coverage, as the schema lacks descriptions). Since there is only one parameter, the baseline is 4, but the description fails to compensate for the schema's lack of detail, such as explaining what 'tex_path' represents or any format requirements, resulting in a reduced score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('extract') and resource ('definitions and lemmas from a TeX file'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'formalize_tex', which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'formalize_tex' or other siblings. It lacks context about prerequisites, constraints, or specific scenarios where extraction is preferred over other operations, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a 'compact JSON summary' but doesn't elaborate on aspects like performance (e.g., speed, data freshness), error handling, or whether it requires specific permissions. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose and output format. Every word earns its place, with no unnecessary details or redundancy, making it highly efficient for quick understanding.
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 has an output schema (which should define the return structure), the description doesn't need to detail return values. However, with no annotations and minimal parameter guidance, it provides only basic purpose and output format. For a tool that likely interacts with project data, this is adequate but leaves gaps in usage context and behavioral traits.
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 one parameter ('project_root') with 0% description coverage, and the tool description doesn't mention any parameters. Since there are zero parameters documented in the description, the baseline score is 4, as the description doesn't need to compensate for schema gaps. However, it misses an opportunity to clarify the optional 'project_root' parameter's role.
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: 'Return a compact JSON summary of progress: entity counts and tasks by state.' It specifies the verb ('Return'), resource ('summary of progress'), and key content ('entity counts and tasks by state'). However, it doesn't explicitly differentiate this from sibling tools like 'tasks_list' or 'render_entities_markdown', which might also provide progress-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'tasks_list' or 'render_entities_markdown' that might offer similar or overlapping functionality, nor does it specify contexts or prerequisites for usage. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns instructions, implying a read-only operation, but doesn't disclose behavioral traits like response format, potential errors, or whether it's idempotent. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with zero waste. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, output schema exists), the description is minimally adequate. However, with no annotations and an output schema, it could benefit from more context on what the instructions cover or typical use cases, but it's not severely lacking.
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 no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 for this dimension.
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: 'Return quick instructions for using this server in Cursor.' It specifies the verb ('Return') and resource ('quick instructions'), though it doesn't explicitly differentiate from siblings like 'ping' or 'progress_summary' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., for new users), or exclusions, leaving the agent to infer usage based on the purpose 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 that the tool 'Returns number of tasks created,' which is useful, but fails to describe other critical behaviors such as permissions needed, whether it modifies existing data, error handling, or rate limits. For a tool that creates tasks, this omission is significant and reduces 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 highly concise and front-loaded, consisting of two sentences that directly state the tool's function and return value. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse for an agent.
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 complexity (task creation with 2 parameters), no annotations, and an output schema (which likely covers return values), the description is minimally adequate. It explains the core purpose and return, but lacks details on behavioral traits, parameter nuances, and usage context, leaving gaps that could hinder an agent's effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some semantic context: it explains that 'kind' defaults to 'fact' (lemmas) and implies it filters entities without tasks. However, with 0% schema description coverage and 2 parameters, it does not fully compensate by detailing the purpose or format of 'project_root' or other aspects of 'kind.' The baseline is 3 due to the schema's lack of descriptions, but the description provides only partial compensation.
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: 'Create open tasks for entities of given kind that do not already have tasks.' It specifies the verb ('create'), resource ('open tasks'), and target ('entities of given kind'), making the intent understandable. However, it does not explicitly differentiate this tool from its siblings like 'tasks_list' or 'tasks_upsert', which slightly limits its clarity in a broader context.
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 by mentioning 'entities of given kind that do not already have tasks,' suggesting it should be used to generate tasks for untasked entities. However, it lacks explicit guidance on when to use this tool versus alternatives like 'tasks_upsert' or 'tasks_list,' and does not specify prerequisites or exclusions, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 usefully describes the return value ('Returns the task id') and provides important context about the flexible task shape and valid states. However, it doesn't address critical behavioral aspects like whether this is an idempotent operation, what happens with partial updates, authentication requirements, error conditions, or rate limits. The disclosure is helpful but incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero wasted words. The first sentence states the core purpose and return value, followed by essential details about the task shape and states. Every sentence earns its place, and information is front-loaded appropriately for quick comprehension.
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 this is a mutation tool with no annotations, 2 parameters (0% schema coverage), nested objects, and an output schema, the description provides a reasonable baseline. The output schema likely documents the return structure, so the description's focus on the task id is sufficient. However, for a flexible upsert operation with undocumented parameters, more guidance on parameter usage and behavioral expectations would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description fails to compensate for this gap. While it mentions the 'task' parameter shape and states, it doesn't explain the 'project_root' parameter at all or provide details about the 'task' object structure beyond a basic outline. The description adds some value about task fields but leaves significant parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create or update') and resource ('a task'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'tasks_list' (read-only) and 'tasks_transition' (state changes only), though it doesn't explicitly name those alternatives. The mention of returning 'the task id' adds useful outcome information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'Create or update a task' and mentions the flexible task shape, suggesting this is the primary tool for task creation/modification. However, it doesn't explicitly state when to use this versus alternatives like 'tasks_autogen_from_entities' or 'tasks_transition', nor does it mention prerequisites or exclusions. The guidance is functional but lacks comparative clarity.
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 states the tool returns a 'simple response', implying a read-only, non-destructive operation, but lacks details on response format, latency, error conditions, or side effects. This is adequate for a basic health check but misses richer context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Health check tool') and avoids any wasted words. Every part of the sentence earns its place by clarifying purpose and output.
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 (0 parameters, no annotations, but with an output schema), the description is reasonably complete. It explains what the tool does and what it returns, though it could benefit from more context on typical use cases or response details. The presence of an output schema reduces the need to describe return values in the description.
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 the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it appropriately focuses on the tool's function. A baseline of 4 is justified as no parameters are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'Health check tool' that returns a 'simple response', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'progress_summary' or 'tasks_list', which might also return status information, so it doesn't fully distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention use cases like verifying server connectivity, testing API availability, or checking system status, nor does it reference sibling tools that might serve similar diagnostic purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return format ('JSON array of results per file') and naming behavior, which adds some context. However, it doesn't describe what 'formalize' entails operationally (e.g., what transformations occur), potential side effects, error handling, or performance characteristics. For a batch processing 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 extremely concise with only three sentences, each delivering essential information: scope, parameter behavior, and return format. It's front-loaded with the core action and wastes no words. The structure efficiently communicates key details without 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 2 parameters, 0% schema coverage, no annotations, but with an output schema (which handles return values), the description provides adequate context. It covers the tool's scope, parameter semantics for naming, and output structure. However, it lacks details on what 'formalize' means operationally and any prerequisites, which would be helpful given the complexity of batch file processing.
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 0%, so the description must compensate. It explains the 'naming' parameter's behavior ('by_file' → module name from file stem, otherwise use "Main") and implies 'project_root' specifies the directory path. This adds meaningful semantics beyond the bare schema, though it doesn't detail parameter constraints or formats. With 2 parameters and good clarification of the optional one, it earns above baseline.
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 ('Formalize all *.tex') and target resource ('under <project_root>/tex'), making the purpose understandable. It distinguishes from sibling 'formalize_tex' by indicating batch processing of all files rather than a single file, though it doesn't explicitly name the alternative. The description avoids tautology and provides specific scope information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the project_root parameter and the 'all *.tex' scope, suggesting this is for batch processing of LaTeX files in a project. However, it doesn't explicitly state when to use this versus 'formalize_tex' or other siblings, nor does it provide prerequisites or exclusions. The guidance is functional but lacks explicit comparative direction.
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 creating a directory layout with specific components (TeX, rules, placeholders) but doesn't disclose behavioral traits like whether it overwrites existing directories, what permissions are required, error handling, or the structure of created files. The description is functional but lacks operational transparency.
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 appropriately sized with a clear purpose statement followed by an Args section. The first sentence efficiently conveys the core functionality, and the parameter explanations are front-loaded and necessary. There's minimal waste, though the structure could be slightly more integrated rather than separate sections.
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 2 parameters with 0% schema coverage and no annotations, the description provides basic purpose and parameter semantics. However, as a creation tool with an output schema (implied by context signals), it doesn't explain return values or error conditions. The description is adequate for simple use but lacks depth for complex scenarios like handling existing directories or detailed output.
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 0%, so the description must compensate. The Args section adds meaningful semantics: it explains that project_name creates a directory and that base_dir is optional with a default location. This clarifies parameter roles beyond the schema's basic titles, though it doesn't detail format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a minimal formalization project layout') and specifies the resources involved ('with TeX, rules, and placeholders'). It distinguishes from sibling tools like 'formalize_tex' or 'workflow_formalize_all' by focusing on initial project scaffolding rather than content processing or comprehensive workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'minimal formalization project layout' and the Args section mentions default behavior for base_dir. However, it doesn't explicitly state when to use this tool versus alternatives like 'quickstart_message' or 'workflow_formalize_all', nor does it provide exclusions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

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