Skip to main content
Glama
gleachkr
by gleachkr

prove_lean_code

Submit Lean code to automatically fill 'sorry' placeholders and generate proofs using the Aristotle theorem proving API.

Instructions

Submits Lean code directly to Aristotle to fill in 'sorry' placeholders. Returns the Project ID immediately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lean_codeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • main.py:127-145 (handler)
    The main handler function for the 'prove_lean_code' tool. It is registered via the @mcp.tool() decorator. This function takes Lean code as a string, submits it to Aristotle's Project.prove_from_file for proving (filling 'sorry' placeholders), adds the project to monitored_projects, and returns the project ID.
    async def prove_lean_code(
        lean_code: str,
        ctx: Context | None = None,
    ) -> str:
        """
        Submits Lean code directly to Aristotle to fill in 'sorry' placeholders.
        Returns the Project ID immediately.
        """
        if ctx:
            await ctx.info("Submitting Lean code to Aristotle...")
        
        project_id = await Project.prove_from_file( # type: ignore
            input_content=lean_code,
            project_input_type=ProjectInputType.FORMAL_LEAN,
            wait_for_completion=False
        )
        
        monitored_projects.add(project_id)
        return f"Project started with ID: {project_id}."
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 that the tool 'submits' code and 'returns the Project ID immediately,' indicating an asynchronous or queued operation with a quick acknowledgment. However, it lacks details on permissions, rate limits, error handling, or what 'Aristotle' entails (e.g., a proof assistant), making behavioral traits insufficiently transparent for a tool with no annotation support.

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: two sentences that efficiently convey the action and immediate outcome. Every word earns its place, with no redundant or vague phrasing, making it easy 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 the tool's complexity (submission to a proof system), lack of annotations, and an output schema (which handles return values), the description is partially complete. It covers the core purpose and acknowledgment behavior but misses usage guidelines, parameter details, and behavioral context like error cases. The output schema reduces the need to explain returns, but other gaps remain, making it adequate but with clear omissions.

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 input schema has 1 parameter with 0% description coverage, so the description must compensate. It implies 'lean_code' is the code to submit, but adds no details on format, constraints, or examples. Since schema coverage is low, the description provides minimal semantic value beyond the parameter name, meeting the baseline for moderate schema coverage but not fully compensating for the 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 tool's purpose: 'Submits Lean code directly to Aristotle to fill in 'sorry' placeholders.' It specifies the verb ('submits'), resource ('Lean code'), and target system ('Aristotle'), and distinguishes it from siblings like 'prove_lean_file' by specifying direct code submission. However, it doesn't explicitly differentiate from 'prove_informal' or 'prove_informal_text', which slightly reduces clarity.

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 'prove_lean_file' (for files) or 'prove_informal' (for informal proofs). It mentions 'fill in 'sorry' placeholders,' which implies a context of incomplete proofs, but lacks explicit when/when-not instructions or prerequisites, leaving usage ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/gleachkr/aristotle-mcp'

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