Numina-Lean-Agent: An Open and General Agentic Reasoning System for Formal Mathematics
Abstract: Agentic systems have recently become the dominant paradigm for formal theorem proving, achieving strong performance by coordinating multiple models and tools. However, existing approaches often rely on task-specific pipelines and trained formal provers, limiting their flexibility and reproducibility. In this paper, we propose the paradigm that directly uses a general coding agent as a formal math reasoner. This paradigm is motivated by (1) A general coding agent provides a natural interface for diverse reasoning tasks beyond proving, (2) Performance can be improved by simply replacing the underlying base model, without training, and (3) MCP enables flexible extension and autonomous calling of specialized tools, avoiding complex design. Based on this paradigm, we introduce Numina-Lean-Agent, which combines Claude Code with Numina-Lean-MCP to enable autonomous interaction with Lean, retrieval of relevant theorems, informal proving and auxiliary reasoning tools. Using Claude Opus 4.5 as the base model, Numina-Lean-Agent solves all problems in Putnam 2025 (12 / 12), matching the best closed-source system. Beyond benchmark evaluation, we further demonstrate its generality by interacting with mathematicians to successfully formalize the Brascamp-Lieb theorem. We release Numina-Lean-Agent and all solutions at https://github.com/project-numina/numina-lean-agent.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper introduces Numina-Lean-Agent, a smart computer system that can do formal mathematics. Formal math means writing proofs in a way a computer can check step-by-step, so there’s no doubt they’re correct. The system uses a “coding agent” (think of a very capable programming assistant) to talk to the Lean proof checker and other tools. The goal is to make solving and checking hard math problems easier, more flexible, and more reliable.
What questions were the researchers trying to answer?
The paper looks at a few simple but big questions:
- Can a general coding agent (not a special math-only model) act as a strong formal math reasoner?
- Can we improve performance just by swapping in a stronger underlying LLM, without extra training?
- Can we build a flexible “plugin” system so the agent can use different tools (like search, planning, or other models) whenever needed?
- Will this approach work not only on contest problems but also when collaborating with human mathematicians on tough research theorems?
How did they do it?
They built Numina-Lean-Agent by combining a strong coding model (Claude Code) with a set of helpful tools (Numina-Lean-MCP). Here’s how the parts work, using everyday analogies:
- Lean proof checker: Lean is like a super strict math teacher. If you write a proof, it checks every step and only accepts it if it’s 100% correct.
- Coding agent (Claude Code): This is the “brain” that plans, writes, and fixes proofs, like a very good programmer who also understands math.
- MCP “plugin system”: MCP is like a power strip for tools. It lets the agent plug in new tools easily and call them when needed.
To keep it simple, here are the main tools the agent can use:
- Seeing the problem clearly: Tools that show the current goal, errors, and the proof’s structure. This is like checking your homework instructions and teacher feedback before continuing.
- Trying strategies quickly: Tools that let the agent test multiple proof ideas in parallel and see which ones work. Like trying different routes on a map to find the fastest path.
- Finding known theorems: Tools that search math libraries for helpful lemmas or definitions. Like using a smart encyclopedia to find the exact fact you need.
- LeanDex (semantic search): A more flexible search that understands natural language questions. Think of it as “Google for Lean math,” but tuned for the math library.
- Informal Prover (Generator + Verifier): One model proposes a step-by-step solution, and another checks it. If it’s wrong, the checker explains why, and the proposer tries again. This loop repeats until it looks solid. It’s like writing a draft essay, getting feedback, and revising.
- Discussion Partner: When stuck, the agent can “ask other models” for fresh ideas. This is like having study buddies who suggest different ways to solve a problem.
- Subagents for hard problems: If a task is too big, the agent breaks it into smaller subproblems, solves them one by one, and then assembles the final proof. It’s like splitting a big project into manageable tasks.
For very long or complicated theorems, the agent also creates a “blueprint”:
- Blueprint planning: A blueprint is a high-level plan listing definitions and lemmas needed, and how they depend on each other. As the agent tries proofs, it uses Lean’s feedback to adjust the plan. This is like making a project outline, then refining it whenever you discover something wasn’t clear enough.
What did they find, and why is it important?
- Top performance on Putnam 2025: The Putnam is a famous, very tough university-level math competition. The agent produced formal solutions to all 12 problems, matching the best closed-source system and outperforming another strong competitor on 2 problems. This shows the approach is competitive at a very high level.
- Efficient and concise proofs: Even without running things in parallel, the agent solved some problems faster than other systems. On many problems, its final Lean proofs were shorter than other agent-based provers.
- Better with feedback loops: When comparing two ways to generate informal solutions—iterative refinement versus independent sampling—the feedback-driven method won clearly. It reached a correct formal proof faster because it learned from its mistakes each round.
- Breaking down hard problems works: On a particularly tricky problem (A5), using subagents to isolate a key lemma helped the system finish the proof more reliably.
- Human-AI collaboration on a research theorem: The team worked with mathematicians to formalize parts of the Brascamp–Lieb inequalities, a deep result in analysis. Over less than two weeks, the agent helped produce over 8,000 lines of Lean code and even invented around 70 new definitions/lemmas. Importantly, the agent sometimes noticed when a statement itself was wrong or too weak and suggested fixing it—this is more than just proving; it’s active mathematical reasoning.
- Limitations: The agent’s proofs sometimes get long and not very “elegant.” It can struggle with tricky type conversions (like moving between number types), which don’t come up much in pencil-and-paper math but matter a lot for formal proofs. And while the proofs are correct, expert Lean users might find them less polished than ideal.
What does this mean for the future?
Numina-Lean-Agent shows that a general coding agent, equipped with a flexible tool system, can be a powerful math co-pilot:
- It can handle diverse tasks beyond proving, like planning, searching, and discussing.
- It gets better by swapping in stronger base models, without extra training.
- It encourages open, reproducible research by sharing tools and methods.
- It helps bridge the gap between human “idea-level” math and computer-checked “formal” math, which could make research more reliable and easier to build upon.
In the long run, this could mean:
- Faster, more trustworthy math proofs and textbooks.
- Better collaboration between mathematicians and AI on complex problems.
- New ways to teach and learn math, supported by systems that check correctness and suggest improvements.
There is still room to improve style, readability, and handling of formal type details, but the core result is promising: a general-purpose agent can already compete at the highest levels of formal math problem solving and support real research formalization.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a focused list of what remains missing, uncertain, or unexplored, framed to guide follow-up research and engineering work.
- Tool-selection policy and reproducibility: The agent’s strategy for autonomously choosing among Lean-LSP-MCP, LeanDex, Informal Prover, and Discussion Partner is not specified or formalized. Provide a documented decision policy (heuristics or learned controller), release prompts/configuration/seeds, and quantify cross-run variance to enable reproducibility.
- Dependence on closed-source LLMs: The system relies on Claude Opus 4.5, Gemini-3-Pro-Preview, and GPT-5.2, with unknown sensitivity to model choice. Evaluate robustness with open-source/base-model variants, report performance deltas, and identify minimal capabilities required for parity.
- Retrieval quality and coverage (LeanDex vs. loogle/local search): No quantitative evaluation of retrieval precision/recall, latency, or coverage across mathlib/FLT/user projects. Build and publish a benchmark for Lean theorem retrieval, including type-aware matching, update strategies across Lean versions, and ablations.
- Informal Prover verification reliability: Triple-pass verification may still admit false positives/negatives, and results are shown on a single problem (B4). Measure verification accuracy across a diverse suite, compare iterative refinement vs. independent sampling at scale, and characterize failure modes.
- Compute/time accounting and efficiency: Table 3 lacks concrete runtimes; compute budgets are approximate; MCP overhead and tool-call counts are unreported. Provide per-problem wall-clock time, token usage, tool-call statistics, and a parallelization study to identify bottlenecks and scaling behavior.
- Potential data contamination in Putnam-2025: The paper does not assess whether base models memorized Putnam solutions or related materials. Conduct leakage checks (e.g., prompt-guard variants, held-out rephrasings, red-teaming) and report contamination risk.
- Subagent mechanism generality: The subagent approach is only demonstrated for A5, with no criteria for when to trigger decomposition or how to partition contexts. Formalize detection of “too-long context” conditions, define decomposition policies/interfaces, and evaluate generalization across tasks.
- Blueprint generation methodology: The blueprint is described qualitatively with no algorithm, metrics, or release of templates/transcripts. Specify generation/refinement procedures, dependencies encoding, decision criteria for lemma granularity changes, and quantify impact on success rate and effort.
- Brascamp–Lieb formalization completeness: The appendix includes “sorry,” and the full cleaned code is not available. Report the proportion of remaining “sorry”s, release the finalized code, quantify agent vs. human contributions, and document proof coverage and correctness beyond compilation.
- Type-level obstacles and coercion planning: Type conversions (e.g., Real ↔ NNReal) cause failures and slowdowns. Develop type-aware planning (coercion maps, canonical equivalences, typeclass hints), integrate automated coercion strategies, and evaluate reductions in type-induced failures.
- Formal elegance and idiomatic Mathlib usage: Proofs are verbose and tactic-heavy, with no metrics for elegance. Define and measure conciseness/abstraction/idiomaticity (e.g., tactic diversity, lemma reuse), build automatic refactoring passes, and run expert reviews/user studies.
- Multi-LLM discussion partner governance: The system lacks a policy for aggregating/conflict-resolving external suggestions, and its net benefit is unquantified. Design a selection/aggregation mechanism (e.g., voting, confidence scoring), evaluate cost-benefit, and characterize when it helps/hurts.
- Cross-proof-assistant portability: The paradigm is only evaluated on Lean v4.26.0. Test portability to Coq/Isabelle/HOL Light, identify MCP-equivalent interfaces, and document adjustments needed for tactic ecosystems and libraries.
- Version robustness and maintenance: Compatibility across Lean versions/Mathlib updates and retriever reindexing are not addressed. Establish regression tests, CI pipelines for indexing updates, and compatibility policies.
- Parallelization and scheduling: All runs were strictly sequential. Investigate parallel proof branch exploration, dynamic scheduling, caching/memoization across attempts, and measure scalability gains vs. costs.
- Safe use of retrieved lemmas: There is no audit of incorrect instantiations or misuse of retrieved theorems. Add sanity checks (type/instance compatibility, precondition verification), log and quantify misuse rates, and build corrective feedback loops.
- Human-in-the-loop productivity: The collaboration case is anecdotal; productivity gains and division of labor are unquantified. Run controlled studies measuring human time saved, agent-added value (new definitions/lemmas accepted upstream), and quality impacts.
- Long-horizon memory and context management: The system reports degraded instruction-following in long contexts but offers no general mechanism beyond ad hoc subagents. Explore external scratchpads/state summarization, hierarchical memory, and context window management policies with metrics.
- Broader benchmarks and generality: Beyond Putnam and one research case, coverage is limited. Evaluate on miniF2F, IMO-Formal, Mathlib PRs, and domain-specific corpora; report cross-benchmark performance and failure analyses.
- Release completeness and traceability: It is unclear whether full interaction logs, prompts, tool call traces, and seeds are released. Provide full experiment artifacts for traceability and comparative studies.
- Comparison fairness: Budgets, parallelism, and hardware differ across systems; proof-length comparisons lack exact numbers in Table 4. Establish a standardized evaluation protocol (compute caps, hardware, parallelism settings), and publish complete tables.
- Economic feasibility: Large budgets for A5/B6 are reported without exact accounting or scaling analysis. Provide precise cost breakdowns, sensitivity to budget, and guidelines for community replication.
- Failure taxonomy: There is no systematic breakdown of errors (tactic failures, typeclass inference, retrieval mismatches, planning errors). Publish a taxonomy and per-problem/error distributions to inform targeted fixes.
- Safety of statement modification: The agent’s ability to revise incorrect statements is promising but unguarded. Define guardrails to maintain theorem intent, log modifications, and provide auditor tools to verify equivalence or intended weakening/strengthening.
- LeanDex maintenance and user-project support: Policies for indexing third-party packages, incremental updates, and reproducibility are not articulated. Document procedures, provide tooling for user projects, and measure search quality in non-mathlib contexts.
- Informal-to-formal alignment: The mapping from verified informal solutions to Lean tactics is not formalized or measured. Build alignment tools, measure translation success rates, and identify common gaps requiring new lemmas or rephrasings.
- Privacy/offline operation: Discussion Partner uses external LLMs; data handling and offline alternatives are not discussed. Document privacy policies, provide offline model options, and measure performance trade-offs.
Practical Applications
Immediate Applications
The following applications can be deployed now using the paper’s released tools (Numina-Lean-Agent, Lean-LSP-MCP, LeanDex) and demonstrated workflows (blueprints, discussion partner, iterative verify–refine, subagents).
- Lean library contributor assistant for mathlib and research repos — AI-assisted drafting, refactoring, and shortening of Lean proofs; automatic retrieval of relevant lemmas; proof-state aware troubleshooting (e.g., “apply field_simp before ring”). Sectors: software (open-source), academia. Workflow/Product: VS Code/GitHub bot that uses Lean-LSP-MCP + LeanDex + Claude Code to propose diffs, fill sorrys, and reduce proof length; pre-merge CI suggestions. Assumptions/Dependencies: Lean 4.26+, mathlib index, MCP servers, commercial LLM APIs (Claude/Gemini) or strong open alternatives, CI integration, contributor review.
- Blueprint-driven formalization service for new results — Turn preprints into machine-checked Lean developments via recursive blueprinting (DAG of lemmas), iterative formalization, and multi-model discussion for bottlenecks. Sectors: academia (pure/applied math, CS theory). Workflow/Product: “Numina Formalization Studio” offering: ingest manuscript → generate blueprint → agent formalizes → human-in-the-loop edits → artifact submission to mathlib or project repo. Assumptions/Dependencies: Availability of domain definitions in Lean libraries or willingness to author new ones; expert oversight for style and library integration; API budgets.
- Course support: grading and tutoring in formal mathematics — Autograding of homework via Lean compilation; “vibe proving” interactive tutor that converts informal steps into Lean proof sketches and explains failures. Sectors: education (universities, MOOCs). Workflow/Product: LMS plugin that runs Lean checks; a teaching assistant mode combining Informal Prover + Lean-LSP-MCP to guide students from ideas to verified proofs. Assumptions/Dependencies: Course materials formalized (at least partially) in Lean; sandboxed compute; student data privacy; modest GPU/API budgets.
- Verify-and-refine coding pipelines for proof-heavy code — Apply the generator–verifier loop to proof-carrying development (e.g., verified algorithms and data structures). Sectors: software engineering (formal methods), security. Workflow/Product: CI step where the agent attempts to discharge contracts/specs in Lean (or produce counterexamples/patch suggestions), using subagent decomposition for long contexts. Assumptions/Dependencies: Specs encoded in Lean or a bridge to Lean; unit/property tests for fast verification; developer acceptance of proof style gaps.
- Smart contract invariant checking (pilot) — Formally specify critical invariants (e.g., conservation, bounds, reentrancy guards) and have the agent search for Lean proofs or generate high-signal counterexamples/informal outlines. Sectors: finance (DeFi), security. Workflow/Product: “Proof Triage” tool that couples Lean models for token/accounting abstractions with agentic retrieval and search; reports proof attempts and failure loci for auditors. Assumptions/Dependencies: Faithful Lean models of the contract semantics (or a sound abstraction); narrow scope (targeted invariants); legal/compliance review; LLM access.
- Research reproducibility triage bot — Attempt formal restatement and proof of claims in arXiv preprints (starting with inequalities, combinatorics, algebra), flagging statements that fail verification or need reformulation. Sectors: academia, scholarly publishing. Workflow/Product: Publisher or lab bot that runs blueprint generation + informal proof + Lean attempt; produces a reproducibility report with links to proof states and missing lemmas. Assumptions/Dependencies: Domain coverage in Lean; author collaboration for intended semantics; compute budget and queueing; respectful, opt-in workflows.
- Editor-integrated semantic theorem search — LeanDex as a semantic retrieval companion for mathlib and project packages, tolerant of natural language and informal queries. Sectors: academia, open-source. Workflow/Product: Editor plugin/CLI that surfaces relevant theorems/defs with usage snippets; complements loogle and local search. Assumptions/Dependencies: Up-to-date indexes; robust embedding models; cost for periodic reindexing.
- Multi-LLM “discussion partner” for stuck proof states — On-demand second opinions that propose alternative strategies or lemma splits, improving success rate on hard goals. Sectors: academia, software (formal methods). Workflow/Product: Toggle in the proving UI that packages current goal/context and queries auxiliary models; merges suggestions into the planning loop. Assumptions/Dependencies: API keys for multiple models; guardrails for privacy (no internet retrieval if required); human oversight.
- Concision and cleanup passes on existing proofs — Automatically propose shorter or more idiomatic Lean scripts post-success, leveraging Lean goal inspection and retrieval of higher-level lemmas. Sectors: open-source, academia. Workflow/Product: “Proof Polisher” that runs after a passing proof to suggest refactors and lemma reuse; shows size/time deltas. Assumptions/Dependencies: Style guides; acceptance tests; risk of regressions mitigated by Lean checks.
- Internal math/CS theory assistance for R&D teams — Rapid exploration of lemmas and bounds (e.g., convexity, combinatorics) with verified artifacts for whitepapers and patents. Sectors: software, AI labs, telecoms. Workflow/Product: On-call agent that searches for reusable lemmas, drafts formal statements, and returns compilable Lean snippets for documentation. Assumptions/Dependencies: Scoped to domains with good Lean coverage; IP and confidentiality controls; expert review.
Long-Term Applications
These require further research, tooling, scaling, or ecosystem development (e.g., broader libraries, stronger/open base models, domain encodings, performance/latency improvements).
- Enterprise-grade safety cases with machine-checked evidence — End-to-end assurance for avionics, automotive, medical devices: control invariants, scheduler properties, and fail-safe proofs embedded in certification packages. Sectors: robotics, automotive, aerospace, healthcare. Workflow/Product: “Assurance Workbench” combining system models, contracts, and formal proofs via agentic planning and subagents; traceability from requirements to Lean artifacts. Assumptions/Dependencies: Rich domain models (hybrid/continuous dynamics), tool qualification, regulator acceptance of Lean-based artifacts, deterministic on-prem inference.
- Verified financial models and regulatory stress tests — Formal guarantees for risk aggregation, bounds on exposure metrics, and monotonicity/convexity properties of pricing/risk engines. Sectors: finance, fintech, regulation. Workflow/Product: Formal specs of core models + agentic proving; audit trails and counterexample-driven refinement; regulator dashboards. Assumptions/Dependencies: Industrial-scale data abstractions; alignment between regulatory definitions and formal semantics; secure, audited infra.
- Textbook-scale formalization and living libraries — Semi-automated conversion of entire courses/monographs (analysis, algebra, probability) into interconnected, verified Lean libraries with pedagogy-aware interfaces. Sectors: education, academia, edtech. Workflow/Product: “Formal Textbook Pipeline” that ingests chapters → blueprint → formalization → interactive exercises; continuous improvement via contributor feedback. Assumptions/Dependencies: Significant library build-out; style/maintainability tooling; improved proof elegance and readability.
- Autonomous research assistants for theorem discovery and repair — Agents that propose conjectures, search for counterexamples, refine statements, and close long-horizon proofs with minimal human intervention. Sectors: academia, industrial research. Workflow/Product: Closed-loop “plan–formalize–refine” with automated lemma mining, subagent orchestration, and multi-model debate; publishes artifacts with proof certificates. Assumptions/Dependencies: Stronger base models, scalable search, robust self-correction, compute-efficient parallelization.
- Cross-domain formal reasoning beyond pure math — Formal encodings for physics (continuum models), cryptography protocols, networked systems, and ML safety properties (e.g., robustness, fairness constraints). Sectors: energy, telecom, cybersecurity, AI safety. Workflow/Product: Domain-specific formal libraries + agent adapters; hybrid numeric–symbolic workflows; verified simulation bounds. Assumptions/Dependencies: Mature domain libraries, solver integrations (SMT/ODE), validated abstractions, performance engineering.
- Regulatory-grade reproducibility and claims verification — Journals and agencies require machine-checkable artifacts for theoretical claims or safety assertions; standardized submission and review pipelines. Sectors: policy, publishing, standards bodies. Workflow/Product: Submission toolchain that packages proofs, indexes, and re-run scripts; reviewer dashboards with Lean feedback and diffs. Assumptions/Dependencies: Community standards for formats/metadata; long-term artifact hosting; impartial governance.
- Proof quality and style transformation — Learned refactoring agents that transform “result-oriented” proofs into idiomatic, abstract, and maintainable code consistent with community norms. Sectors: open-source, academia. Workflow/Product: “Proof Styler” trained on curated corpora; enforces abstraction boundaries, introduces reusable lemmas, and documents intent. Assumptions/Dependencies: Datasets of exemplar proofs; evaluators for readability/maintainability; human-in-the-loop acceptance.
- Unified tool orchestration via MCP across engineering stacks — A generalized agent layer that coordinates theorem provers, solvers, static analyzers, and documentation systems with autonomous tool selection. Sectors: software, DevEx, platform engineering. Workflow/Product: Enterprise MCP hub with policy/routing, credentials, and observability; reusable skills for retrieval, verification, and planning. Assumptions/Dependencies: Standardized MCP adoption, security hardening, provenance tracking, role-based access.
- Low-latency, on-device formal assistants — Private, offline theorem and spec assistants for sensitive IP and regulated environments. Sectors: defense, healthcare, finance. Workflow/Product: Quantized/open base models fine-tuned for proof interaction; local Lean + indexes; partial parallel search. Assumptions/Dependencies: Sufficiently strong open models; hardware acceleration; memory-efficient indexes.
- Formalization-aware programming languages and compilers — Tight loops between code and proofs (proof-carrying code, refinement types, certified compilation) with agentic assistance to maintain invariants during refactors. Sectors: software, embedded systems. Workflow/Product: IDEs that co-evolve code and Lean specs, auto-suggesting lemmas after API changes; certified build pipelines. Assumptions/Dependencies: Language/Lean bridges, library maturity, DevEx investment, cultural adoption.
Notes on feasibility across applications
- Current strengths: tool-use autonomy (MCP), semantic retrieval (LeanDex), iterative verify–refine, subagent decomposition, human–AI co-authoring (blueprints).
- Current limitations to plan for: reliance on closed LLMs, cost/latency, type-level brittleness and long-context degradation, proof elegance/style gaps, domain library coverage.
- Risk mitigations: on-prem deployment, stronger/open base models, better type-handling heuristics, proof polishing passes, and incremental domain library growth.
Glossary
- Agentic: Pertaining to autonomous, tool-using workflows where models plan and act to solve tasks. "Agentic systems have recently become the dominant paradigm for formal theorem proving, achieving strong performance by coordinating multiple models and tools."
- AxiomProver: A closed-source, autonomous multi-agent theorem proving system. "AxiomProver (Axiom Math Team, 2025), developed by Axiom Math, adopts an autonomous multi-agent ensemble architecture"
- Blueprint: A structured plan that decomposes a target theorem into definitions and intermediate lemmas with explicit dependencies. "A blueprint is a design-document-style artifact consisting of (i) required definitions and notation, (ii) a curated list of intermediate lemmas with suitable granularity, and (iii) the final theorem whose proof largely composes these lemmas."
- Brascamp-Lieb theorem: A fundamental result in analysis concerning inequalities that generalize Hölder and Loomis–Whitney; here, a target of formalization. "to successfully formalize the Brascamp-Lieb theorem."
- DAG: Directed acyclic graph; used to encode lemma dependencies and proving order. "forming a DAG that determines proving order and reduces ambiguity during search."
- Discussion Partner: A tool that lets the agent consult external LLMs for alternative strategies or hints. "a Discussion Partner tool enables querying external LLMs to assist in reasoning and planning."
- field_simp: A Lean tactic that clears denominators and simplifies rational field expressions. "Apply field_simp first. You need to clear the denominators before ring can solve the polynomial."
- Informal Prover: A component that produces and verifies informal mathematical solutions in an iterative refinement loop. "An Informal Prover (Huang & Yang, 2025) is used to generate detailed informal proof solutions,"
- Isabelle: An interactive theorem prover for formal logic and mathematics. "such as Lean (2015) and Isabelle (Paulson, 1994)."
- Language Server Protocol (LSP): A standard protocol for language tooling used here to interface with the Lean environment. "Acting as a bridge between LLMs and the Lean kernel via the Language Server Protocol (LSP)"
- Lean (Lean theorem prover): An interactive theorem prover and proof assistant for formal mathematics. "designed for the Lean theorem prover."
- Lean kernel: The core proof-checking engine of Lean responsible for verifying proofs. "Acting as a bridge between LLMs and the Lean kernel via the Language Server Protocol (LSP)"
- Lean-LSP-MCP: An MCP server exposing Lean’s LSP-based tools for agentic interaction and proof manipulation. "Lean-LSP-MCP (Dressler, 2025) is a Model Context Protocol (MCP) server explicitly designed for the Lean theorem prover."
- LeanDex: An agentic semantic search tool for finding Lean theorems and definitions across packages. "LeanDex. We present a new theorem search tool for Lean that supports theorem retrieval under Lean v4.26.0."
- LeanExplore: A semantic search framework on which LeanDex builds to improve retrieval for Lean libraries. "Built on top of LeanExplore, it extends the underlying semantic search framework with enhanced reasoning and retrieval capabilities, significantly improving both flexibility and coverage."
- lean_goal: A Lean-LSP-MCP tool to query the current proof goal precisely. "to lean_goal for precise goal querying,"
- lean loogle: A tool for searching the Mathlib repository via natural language or structured queries. "lean loogle facilitates searching the massive Mathlib repository via natural language or structured queries."
- lean_local_search: A tool for searching definitions and theorems in local Lean projects and the standard library. "lean_local_search focuses on mining definitions within local lean projects and the standard library (stdlib)"
- lean multi_attempt: A tool to try multiple proof strategies in parallel at a single proof node. "utilizes lean multi_attempt to allow parallel execution and evaluation of multiple strate- gies at a single proof node."
- lean_run_code: A tool to compile and execute isolated Lean code snippets instantly. "supports the instant compilation of isolated code snippets via lean_run_code"
- Mathlib: The community-maintained mathematical library for Lean. "the massive Mathlib repository"
- Model Context Protocol (MCP): A protocol for exposing tools to LLMs in a standardized way. "Lean-LSP-MCP (Dressler, 2025) is a Model Context Protocol (MCP) server explicitly designed for the Lean theorem prover."
- Monte Carlo tree search: A stochastic search algorithm used to explore proof spaces by sampling. "such as Monte Carlo tree search, to explore the proof space."
- proof-state inspection: Examining the current goals, hypotheses, and context during formalization to guide next steps. "proof-state inspection may reveal that an informal step is incorrect, underspecified, or split at an unsuitable granularity."
- Putnam 2025 benchmark: A benchmark consisting of the 2025 Putnam problems used to evaluate provers. "We evaluated Numina-Lean-Agent on the Putnam 2025 benchmark"
- ring (Lean tactic): A tactic that solves equalities in commutative semirings by normalizing polynomials. "ring can solve the polynomial."
- semantic search: Retrieval based on meaning (e.g., embeddings) rather than exact text match, used to find relevant theorems. "It is an agentic semantic search tool for Lean, capable of retrieving mathematical theorems and definitions across multiple packages,"
- sorry (Lean placeholder): A placeholder in Lean that marks an unfinished proof. "we mainly tasked the agent with two kinds of 'sorry's of different difficulty."
- subagent: A subordinate agent used to decompose and solve subgoals independently. "we adopt a novel subagent mechanism that decomposes the proof into several subgoals"
- tactic: A scripted command or method that advances a proof state in a proof assistant like Lean. "Early provers relied on tactic prediction combined with explicit search methods,"
- type conversion: Transforming an expression from one type to another within Lean’s type system. "due to a type conversion from Real to NNReal."
- typeclass search: Lean’s mechanism for automatically resolving implicit instances (e.g., algebraic structures). "Lean feedback (failed typeclass search, missing lemmas, mismatched interfaces, etc.)"
Collections
Sign up for free to add this paper to one or more collections.