formal-proof-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct verification or counting task—Lean compilation, axiom auditing, bounds, deadlock detection, certificate verification, residency interpretation, preregistration falsifiability, state floors, gate impact, and evidence aggregation. Even the closest pair, state_floor and gate_count, is clearly separated by what each counts.
Naming Consistency4/5Most tools follow a descriptive object_action pattern such as lean_check, gridlock_check, prereg_check, and cert_verify, and all names use lower-case snake_case. However, bound, state_floor, and gate_count are noun-phrase names rather than action-phrase names, so the convention is not perfectly uniform.
Tool Count5/5Ten tools is within the ideal 3-15 range, and each tool earns its place by covering a distinct aspect of formal proof and evidence verification. The count feels well-scoped for a server spanning Lean checking, axiom auditing, and specialized domain proofs.
Completeness4/5The set covers the main verification lifecycle well: compilation, axiom auditing, certificate verification, evidence aggregation, and several specialty proof checks. The primary gap is the lack of a general proof-construction or proof-search tool, and several tools require external packages, making the surface strong but not fully self-contained.
Average 3.5/5 across 10 of 10 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.jsonto 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 to fall back on, the description carries the full burden of explaining side effects, permissions, and failure modes. It mentions internal computations (digests, gate consistency, false-pass bound) but does not disclose what the tool does beyond that—no mention of errors, required access, or consequences of verification failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—and immediately states the primary action and key verification aspects. It is well-structured, with the action first and the required capability noted at the end, fitting comfortably within a short description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks critical context: no output format or return values are described (no output schema exists), no error conditions are mentioned, and the tool's role relative to sibling tools is not clarified. Given the complexity of the certificate verification process, this is insufficient for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions, and the tool description does not compensate. While 'certificate' is implied by the resource name, there is no explanation of `hmac_key` or `allow_unauthenticated`. This leaves agents without enough information to construct correct arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Verify a signoff-cert/v1 certificate') and lists specific checks (digests, gate consistency, false-pass bound recomputation). It is clear enough to distinguish the tool's primary function from generic 'check' or 'audit' tools, though it does not explicitly name sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the sibling tools. The only contextual hint is 'Requires `signoff-cert`', which suggests a prerequisite but does not clarify when this verification is appropriate or when another tool should be chosen.
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 the full burden. It does disclose that the tool computes an exact count, can test a budget, and requires floorgen, but it omits any mention of return format, side effects, failure modes, or whether this is a safe read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and reasonably compact. The opening rhetorical question is slightly stylistic but not wasteful, and the key capabilities are stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explicitly state what the tool returns, though 'exact count' and 'proves' hint at outputs. It also does not clarify the semantics of default/has_default or the nature of the floorgen dependency, leaving notable gaps for a tool with five parameters and nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the schema already documents most parameters. The description adds some context by referring to an 'enumerated situation space' and 'state budget', which loosely map to variables/answers and budget_states, but it does not meaningfully extend the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool computes an exact state count over an enumerated situation space and optionally proves a given state budget is insufficient. This is a clear, specific action on a defined resource, though it does not explicitly differentiate it from sibling tools such as bound or gate_count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings, nor any exclusions or alternatives. The description implies usage through 'Requires floorgen' and the problem statement, but an agent is left to infer the appropriate 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, the description carries the burden of behavioral disclosure. It clearly states the exact one-sided Clopper-Pearson method and warns that k=0 is not a bound. However, it does not disclose whether the bound is lower or upper, how missing k is handled, or what edge-case behavior occurs, so transparency is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant material, and the core statistical method is prominent. The phrasing is slightly indirect rather than a direct 'Computes...' command, but it is appropriately sized and memorable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse operationally. It omits the direction of the bound, the default/behavior when k is omitted (only n is required), and any parameter validation or return-shape information. The statistical essence is present, but an agent cannot confidently invoke it correctly in all intended cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already labels k as observed failures, n as trials, and confidence with a default. The description adds useful 'one-sided' and 'k-of-n' context and clarifies that a perfect record is not a bound. It does not explain k's optionality/default or confidence range, so it remains around the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool computes an exact one-sided Clopper-Pearson bound for a k-of-n record, which is a concrete and unambiguous purpose. The added warning that 'It passed every time' is not a bound reinforces the tool's role. It does not use an explicit imperative verb or name a sibling, so it misses the top 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over the sibling tools or about prerequisites. The only hint is a conceptual caveat about perfect records, not a selection criterion. An agent would have to infer usage from the statistical terminology.
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 responsibility for behavioral disclosure. It explains an important semantic subtlety: a null result from an evicted cache is not an all-clear, and it defines what `failed` means. It does not mention side effects, permissions, or other possible return states, but the key interpretability trap is clearly surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with two sentences that each add value: one defines the core question and failure semantics, and the other names the required dependency. The rhetorical question is slightly less direct than an explicit imperative, but the description remains tightly structured and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no annotations and no output schema, the description is incomplete: it explains the failure case but not what a successful or interpretable outcome looks like, nor what the parameters mean. It provides purpose, one dependency, and one important semantic caveat, but that is not enough for an agent to invoke the tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation, but it does not explain `model`, `kv_budget_gib`, `n_prefixes`, or `tokens_each`. The cache-probe context hints at the role of `kv_budget_gib`, but an agent would struggle to know what values to supply for the two required parameters and how the optional parameters affect the check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a check on whether a cross-tenant cache probe result can be interpreted, and it specifies a concrete output condition: `failed` when the victim's state could not have stayed resident. It is not a bare tautology and conveys a distinct domain purpose. However, it is phrased as a question rather than a direct verb phrase and does not distinguish itself from sibling tools like `lean_check` or `gate_count`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one operational prerequisite, `Requires kvleak`, which tells the agent that this dependency must be available before calling. The intended use case is implied: use it when you need to know whether a cross-tenant cache probe's result is interpretable given residency. It does not explicitly state when to prefer this over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It reveals that the tool compares `#print axioms` output against an allowlist and that it is designed to catch `sorryAx`. It does not disclose behavior on mismatch, effect (read-only vs write), or handling of the optional `allowed` parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and the second sentence provides valuable motivation without excessive detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient to understand the tool's overall purpose but is incomplete for invoking it correctly: the `allowed` parameter is never precisely defined, and there is no information about return values or failure signaling. For a two-parameter tool with no annotations or output schema, more detail is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the 'allowlist' concept, which maps to the `allowed` parameter that lacks a schema description, but it doesn't specify the expected string format or how violations are reported. The `output` parameter is already described in the schema, so the description adds little there. With 50% schema coverage, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Audit `#print axioms` output against an allowlist') and ties it to a concrete failure mode (`sorryAx`), making the tool's role clear. It does not explicitly compare with siblings like lean_check or evidence_audit, so it doesn't fully earn the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for when this check matters (a clean compile with `sorry` exits 0), implying use when you need to ensure no `sorry` axioms appear. It does not name alternative tools or state when not to use it, leaving the decision partially to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals that the tool returns a count, that zero indicates redundancy, and that `gatecount` is required. However, it does not specify the exact output format, error behavior, or whether there are any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no redundancy. It front-loads the core operation, explains the output interpretation, and notes the external requirement, with every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its moderate complexity (three required parameters, nested objects, no output schema, no annotations), the description is nearly complete. It conveys the result semantics and the `gatecount` prerequisite; only the exact return representation and failure behavior are left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with domain, policy, and weakened all described meaningfully. The description adds no parameter-level detail beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool counts exactly how many states removing a check admits, which is a specific verb-resource-result combination. It also interprets zero as 'REDUNDANT' and explicitly contrasts with the existing 'we found no escapes' output, distinguishing it from sibling check tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance. The phrase 'Replaces we found no escapes with a count' hints that this is a count-oriented alternative to a boolean check, but no sibling tool is named and no selection conditions are given.
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 does reveal a meaningful non-obvious behavior: the verdict is the weakest leg, never the mean, and a prerequisite ('Requires `evidence`') exists. However, it leaves important traits undisclosed, such as what constitutes 'evidence', what the verdict format is, whether the operation is read-only, and how failures are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose and unique aggregation rule are front-loaded, and every clause contributes meaningful information, even if one clause is cryptically worded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an orchestrating tool that runs multiple verifiers and produces a verdict, yet there is no output schema and no annotation. The description does not define what a 'verdict' looks like, what 'every applicable verifier' means in concrete terms, what 'Requires `evidence`' refers to, or what happens if the path is invalid or the evidence is missing. Given the complexity, the description leaves too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter `path` as 'directory to audit', so schema description coverage is 100%. The description adds the 'Requires `evidence`' constraint, which could plausibly tell the agent what must be inside `path`, but it is too ambiguous to clearly enhance parameter understanding. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and a clear resource ('every applicable verifier over a directory'), then adds a precise aggregation rule ('ONE verdict -- the weakest leg, never the mean'). This strongly distinguishes it from sibling tools like lean_check or cert_verify, which appear to be individual verifiers rather than the aggregate audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: call this tool when you want every applicable verifier run and combined into a single verdict. It does not explicitly name alternatives or state when not to use it, but the 'every applicable verifier' phrasing implicitly contrasts with the individual sibling tools. The 'Requires `evidence`' constraint gives some prerequisite context, though it is ambiguous.
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 behavioral disclosure burden and does reasonably well: it explains the core certification, the cycle-returning behavior, and the semantic role of ranks in proving progress. It still does not state what happens when no cycle exists or whether the operation is side-effect free, but the disclosed behavior is meaningful and non-tautological.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded, and every sentence contributes: purpose, normal return behavior, and optional parameter semantics. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the optional ranks behavior well, but because there is no output schema, it should clarify what the tool returns when no cycle exists and how successful certification is represented. The ranks object format is also left vague, though the parameter is optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes edges as '[[waiter, holder], ...]', and the description adds the wait-for relation context. It also explains that ranks are used to verify strict decrease, giving semantic meaning to an otherwise undocumented object parameter, although the exact shape of the ranks object remains underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific operation — certifying that a wait-for relation cannot wedge — and explains that it returns the actual cycle when one exists. It is distinct in substance from the sibling tools, though it does not explicitly name any alternative for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful contextual guidance: supply ranks to check strict decrease, and notes that acyclicity alone is insufficient for bounded progress. However, it does not explicitly state when to use this tool versus the sibling verification tools or when to prefer another check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and actually discloses a concrete behavior: returns UNFALSIFIABLE when the finding or null can never fire over declared supports, and requires preregister. It does not state the return value when the rule is falsifiable, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: when to use, what it returns, and the dependency. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Parameters are fully covered by the schema, but there is no output schema and no annotations, so the description should define the full return contract. It details only the UNFALSIFIABLE case and leaves the falsifiable outcome implicit, which is a meaningful gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents decision_rule and metrics. The description only adds the term 'declared metric supports' and does not go beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('check') and resource ('decision rule') and describes the falsifiability criterion ('CAN come out both ways'). The UNFALSIFIABLE return and prerequisite set it apart from the sibling check/audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Before running an experiment', giving clear temporal context for when to call it. It does not name alternatives or exclusions, but the context plus the distinct UNFALSIFIABLE outcome makes the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that failures return the real error, and that a missing toolchain results in 'unavailable' rather than a pass, giving an honest account of likely outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, direct, and free of unnecessary detail. It front-loads the core purpose and then adds important edge-case behavior efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and failure modes, which is helpful given there is no output schema. However, it does not describe the success response format or timeout behavior, leaving some context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'source' as 'Lean 4 source', and the description's 'snippet' adds little. The 'timeout' parameter has no semantic explanation (e.g., units or default behavior), so the description does not fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compiles a Lean 4 snippet and returns the compiler's verdict, using a specific verb ('compile') and a specific resource ('Lean 4 snippet'). It also distinguishes the tool's behavior in failure and environment-missing cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is appropriate—when a Lean 4 snippet needs checking—and explains failure is repairable. It does not explicitly compare with sibling tools or state when not to use it, so it falls short of a perfect score.
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:
Score Badge
Copy to your README.md: