Lean LSP MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the mutation risk profile is covered. The description adds information the annotations cannot express — that the LSP server is restarted as a side effect — which is important state-changing context for the agent. It does not mention build duration or failure behavior, which the schema only hints at via '(slow)'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste, with the action and its side effect front-loaded before the usage restriction. Nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and all parameters are fully described, so the description only needs to convey purpose, side effects and gating — all of which it does. The only omission is the cost/blocking nature of the build, which is partially covered by the schema's 'slow' notes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each of the four options (clean, fetch_cache, output_lines, lean_project_path) documented including cost warnings. The description adds no parameter-level meaning, so the schema does the work and a baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Build the Lean project') and adds the key side effect ('restart LSP'). It implicitly separates itself from siblings like lean_run_code or lean_verify, but never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear gating condition ('Use only if needed') with a concrete triggering example ('new imports'), which steers the agent away from habitual rebuilding. It stops short of naming the alternative tools to use when a build is not needed.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and idempotentHint=true, matching the read-only nature. Description adds specifics about returning resolved edits for TryThis suggestions, which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the purpose. Every word earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, description sufficiently covers what the tool returns. Mentions specific types of suggestions. Could elaborate on return format but still adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with descriptions (100% coverage). Description does not add any extra detail beyond what schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Get', resource 'LSP code actions for a line', and specifies it returns resolved edits for TryThis suggestions and other quick fixes. Distinct from siblings like lean_build, lean_completions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implicit: it returns code actions for a line. No explicit when-to-use/when-not-to-use or alternative tools mentioned.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that – it does not say what happens on an empty result, whether the file must be part of the open project, or how resolve_details affects cost. Useful but thin given annotations carry most of the burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler, and the core action is front-loaded before the usage caveat. Nothing could be removed without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the input schema is fully documented; the description covers purpose and trigger condition adequately for a simple LSP-backed lookup. Minor gaps remain around preconditions (file must be opened/known to the project) and empty-result behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so line/column indexing, path form, max_completions and resolve_details are all fully documented in the schema. The description adds no positional or formatting guidance beyond it, which matches the baseline for a high-coverage schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Get IDE autocompletions" names a concrete verb and resource, so an agent immediately knows this returns candidate completions rather than diagnostics or goals. It does not explicitly name the sibling it is contrasted with (e.g. lean_hover_info for complete identifiers or lean_local_search for name search), so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives a real usage condition – call it on incomplete code, specifically after `.` or a partial name – which is the key discriminator versus hover/goal tools. There are no explicit exclusions or named alternatives, so it is clear context without routing.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish this as a readOnly, idempotent, closed-world lookup, so the description only needs to add behavior beyond that. It does add two useful facts: generated declarations conditionally include their source declaration, and full_file can return a very large payload. It does not say what happens when the symbol is missing or not found in the given file, which is the main remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each carrying a distinct point (what is returned, generated-declaration behavior, the large-file escape hatch), with the core purpose front-loaded. Nothing is wasted or restated from the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape explanation is properly omitted, and for a simple read tool the description covers purpose, one behavioral nuance, and a size caveat. The only meaningful omission is how this differs from adjacent lookup siblings, which would help an agent pick correctly in a crowded toolset.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so symbol, file_path, full_file, and context_lines are already documented in structured form and the baseline is 3. The description slightly reinforces full_file with a size warning and implicitly links context_lines to 'surrounding context', but adds no format or edge-case meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: retrieve a declaration's source along with its source-line range and surrounding context. That is far more specific than the title alone and distinguishes it from listing tools like lean_file_outline. It stops short of naming a sibling such as lean_hover_info, so the differentiation from related lookup tools is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the stated output (declaration source with line range), but there is no explicit when-to-use versus lean_hover_info, lean_file_outline, or lean_local_search, and no stated preconditions beyond the schema's path/symbol requirements. The one behavioral caveat given is the full_file escape hatch, which guides usage but is not an alternative-selection rule.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the diagnostic categories (errors, warnings, infos) but says nothing about elaboration behavior, timeouts, or polling, which is where the real behavioral nuance lives (and is carried by the schema instead).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the core action front-loaded and no wasted words. Nothing redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the schema covers all parameters. However, for a tool with 7 parameters and non-trivial elaboration/polling behavior, the description is thin on the when-and-why, leaving the agent to reconstruct context from structured fields alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every one of the 7 parameters is already documented (severity enum, timeout polling behavior, line filters, interactive widget caveat). The description adds no parameter detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Get) and resource (compiler diagnostics) scoped to a Lean file, which is clear on its own. It does not distinguish this tool from siblings like lean_goal, lean_hover_info, or lean_code_actions, which also surface Lean analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does 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 the many sibling diagnostics/analysis tools, nor any prerequisite or exclusion stated. The agent must infer usage entirely from the name.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, which cover key behavioral traits. The description adds 'token-efficient', which provides additional context about the output format, but does not disclose any other behaviors like required permissions or side effects. Given the annotations, this is adequate but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two terse sentences (7 words total) that front-load the key action and a performance hint. Every word serves a purpose, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, full parameter descriptions in the schema, comprehensive annotations, and the presence of an output schema, the description provides sufficient context for invocation. It could be slightly more explicit about the output structure, but that is handled by the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents both parameters thoroughly. The description adds no new parameter-specific information beyond the schema's descriptions, earning the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns imports and declarations with type signatures, which directly matches the name 'file_outline'. It distinguishes from siblings like 'lean_declaration_file' which focuses on a single declaration, and 'lean_hover_info' which provides information on specific locations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 does not mention prerequisites, limitations, or when not to use it, leaving the agent to infer usage from the name and purpose alone.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, making the tool's safety profile clear. The description adds extra value by warning that 'data may be large', which is important behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose, and a second sentence providing a critical warning. No unnecessary words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (handling return format), 100% parameter coverage, and the description providing examples and a size warning, the description is complete for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema itself documents all three parameters. The description adds no additional meaning to the parameters, thus baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves panel widgets at a position, listing examples (proof visualizations, #html, custom widgets). It distinguishes from sibling lean_get_widget_source by noting it returns raw widget data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (need panel widgets at a position) but does not explicitly mention when not to use or list alternatives. With many sibling tools, explicit exclusions would be helpful, but the context is still clear.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so safe read. Description adds that 'Returns full JS module - may be large', warning about size, going beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded key action, no redundant words. Each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, and size warning. Output schema exists so return values not needed. Could mention dependency on lean_get_widgets for hash, but not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage with clear parameter descriptions. The tool description adds no extra meaning 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.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Get', resource 'JavaScript source of a widget', and method 'by hash'. Distinguishes from siblings like lean_get_widgets which likely returns widget instances.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly mentions 'Useful for understanding custom widget rendering logic', providing when to use. No explicit when-not or alternatives, but context is clear.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint and idempotentHint, and the description adds crucial behavior: column omission reveals before/after states, timeout handling with 'still_elaborating' status, and possible statuses. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a status explanation. Front-loaded with 'MOST IMPORTANT tool - use often!' which is slightly verbose but adds emphasis. No extraneous information; each sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a proof goal tool with 5 parameters and an output schema (not shown), the description adequately covers behavior, status outcomes, and column handling. No missing critical information for using the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions. The description adds value by explaining the effect of omitting column (goals_before/goals_after) and the meaning of format enum options, which go beyond the schema's parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get proof goals at a position' with a specific verb and resource. It also labels itself as the 'MOST IMPORTANT tool', distinguishing it from siblings like lean_term_goal, lean_state_search, etc., which query different aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to omit column for before/after views, and defines status values like 'complete' and 'no_goal_at_position'. It does not explicitly list when to use this vs. other tools, but the context of proof goals and the 'most important' emphasis provides implicit guidance.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds a rate limit (6req/30s) and specifies the return format (lemma names). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a rate limit. The purpose is front-loaded, every word adds value, and there is no verbosity. Ideal conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 4 parameters, full annotation coverage, and presence of an output schema (implied), the description covers purpose, return type, and rate limit. It lacks examples but is adequate for a straightforward suggestion tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all 4 parameters. The description adds minimal value beyond the schema, only linking line/column to 'goal position'. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides premise suggestions for automation tactics at a goal position, listing specific uses like `simp only [...]`, `aesop`, or hints. This distinguishes it from sibling tools like lean_leansearch or lean_loogle, which are general search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for getting premise suggestions during automated proof attempts, but does not explicitly state when to use this tool versus alternatives like lean_leansearch or lean_loogle. The rate limit is mentioned but not a usage guideline.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that – no mention of build-state dependency or empty results on non-symbols. With annotations carrying the burden, this is minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the action front-loaded. The second sentence is somewhat generic ('Essential for understanding APIs') but costs little and stays brief.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and annotations cover safety. Still, the description omits operational context such as needing an up-to-date build or what happens at non-symbol positions, leaving gaps for a tool whose results depend on file state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with line and column clearly documented as 1-indexed and column defined as the START of the identifier. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Get type signature and docs for a symbol.' An agent can tell what it returns. However, it does not distinguish itself from closely related siblings like lean_completions, lean_goal, or lean_references, which also surface symbol information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is 'Essential for understanding APIs,' which is a generic value claim rather than a when-to-use condition. It never says when to prefer this over siblings such as lean_completions or lean_references, nor any prerequisite (e.g. file must be built/loaded).

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnly, openWorld, idempotent), description adds rate limit, version behavior (default and options), and that it performs semantic search. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two short paragraphs with rate limit, purpose, examples, and parameter explanation. No wasted sentences, information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, description covers purpose, usage constraints, parameter details, and examples. Output schema exists, so return values are covered. No gaps for an agent to select or invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so minimal extra needed. Description adds example queries for the 'query' parameter and explains version options, but adds no new semantic info for 'num_results'. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'semantic search by mathematical meaning via Lean Finder' with examples. Purpose is specific and distinguishable from siblings, but does not explicitly differentiate from similar tools like lean_leansearch or lean_state_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides rate limit (10req/30s) and examples of queries, implying usage for semantic search. However, no explicit guidance on when to use this tool versus alternatives among the many sibling tools.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds rate limit information beyond annotations (readOnlyHint, idempotentHint, openWorldHint). No contradictions. However, does not describe response behavior or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise, front-loaded with rate limit, then purpose, then examples. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with output schema, the description covers purpose, parameters, examples, and rate limit. No gaps given the context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%. Description provides example queries for the 'query' parameter, adding practical meaning. No additional detail for 'num_results' but schema is clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Explicitly states it searches Mathlib via leansearch.net using natural language. Provides concrete examples distinguishing it from sibling search tools like lean_loogle or lean_local_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions rate limit (90req/30s) but does not clarify when to use this tool vs alternatives like lean_leanfinder or lean_loogle. No explicit exclusions or selection criteria.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds "Fast" as a performance trait, but says nothing about search semantics (exact vs. prefix matching, whether it covers dependencies), which is the information annotations cannot supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler, and the timing instruction is placed after the purpose so the agent reads what the tool is before when to call it. Nothing could be cut without losing content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter, read-only search tool with an output schema and full annotation coverage, the description carries everything the agent needs to decide to call it. Return values are handled by the output schema, so no description of results is required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with all three parameters documented in the schema itself (query as name-or-prefix, limit, inferred project_root). The description adds no meaning beyond that — it does not clarify matching behavior or the effect of limit — so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Fast local search" gives a specific verb and a resource scope, and "to verify declarations exist" states the intent. The word "local" implicitly separates it from the external-search siblings (lean_leansearch, lean_loogle, lean_leanfinder), but none of those are named, so differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use BEFORE trying a lemma name" is a real sequencing hint that tells the agent when in a workflow to reach for this tool. However, it never says when NOT to use it, nor does it point to the sibling search tools that cover non-local/external lookup, which the agent must figure out from names alone.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, which cover the tool's behavioral safety and consistency. The description adds no new behavioral traits beyond stating it searches via an external source (loogle.lean-lang.org), which is consistent with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences of purpose and one line of examples. Every part earns its place. The purpose is front-loaded, and the examples are directly helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (search by type signature), the presence of an output schema (not shown but confirmed), and comprehensive annotations, the description is complete. It explains the source, provides examples, and does not need to detail return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value by providing concrete examples of valid query strings, which go beyond the schema's generic description ('Type pattern, constant, or name substring'). The num_results parameter is briefly described in the schema but not elaborated in the description, which is fine given its simplicity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search Mathlib by type signature via loogle.lean-lang.org.' This is a specific verb+resource combination that distinguishes it from sibling tools like lean_leansearch (general search) or lean_leanfinder (name search). Examples further clarify the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete examples of valid queries (e.g., `Real.sin`, `?a → ?b → List ?a → List ?b`), which strongly imply when to use this tool—namely for type-based or pattern-based searches. However, it does not explicitly state when not to use it or name alternatives among siblings.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavior beyond annotations: work happens on scratch copies in parallel, the target file is never edited, and the proof body is not rewritten, so elaboration failure is reported as load-bearing rather than patched. There is mild tension with `destructiveHint: true` / `readOnlyHint: false`, which the description does not explain (likely scratch-document creation/teardown), but the description does not deny a write — it scopes it to the source file.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the skip rules, then the non-rewriting semantics, then the parallelism guarantee. Each of the four sentences carries distinct information and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value shape need not be described, and the description covers the non-obvious semantics an agent needs: skip rules, failure interpretation, and non-mutation of the file. Only the mismatch between the stated no-edit behavior and the destructive annotation is left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so `file_path`, `theorem_name` (bare vs qualified, trailing-segment matching), and `inactivity_timeout` are already documented. The description adds no parameter-level detail of its own; its 'explicit hypothesis' scoping is about what gets tested, not about any input field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource pair: for each explicit `(h : T)` hypothesis, drop it and re-elaborate a scratch copy, reporting load-bearing vs unused. No sibling (`lean_multi_attempt`, `lean_verify`, `lean_goal`) does hypothesis minimization, and the scoping to explicit binders makes the tool unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear selection context: it only touches explicit `(h : T)` hypotheses and deliberately skips implicit `{x : α}` and instance `[inst : C]` binders, with a rationale. It stops short of naming an alternative tool or stating when not to use it at all (e.g., for theorems with no explicit hypotheses).

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description claims the operation happens 'without modifying file', yet annotations declare readOnlyHint=false and destructiveHint=true. If attempts touch editor/buffer state or are reverted afterward, that should be stated; if truly read-only, the annotations are at odds with the text. Either way the agent is left without a reliable side-effect picture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and followed by the return shape; no filler. It is terse to the point of under-specification, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, but for an openWorld, destructive-hinted tool the description should cover side effects on file state, whether attempts are reverted, or cost/rate considerations. Those are absent, and the 'without modifying file' claim leaves the safety profile unresolved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so line, column, snippets, and file_path are already documented in structured fields. The description adds no extra meaning (e.g., what a 'tactic' snippet should look like, whether snippets are full proofs or single tactics), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: try multiple tactics at a position in a Lean file, and returns the resulting goal state for each. This is distinguishable from siblings like lean_goal or lean_run_code, though it never names those alternatives to sharpen the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance: no mention of when to prefer this over lean_run_code, lean_hammer_premise, or lean_code_actions, and no prerequisites (e.g., file must be open/elaborated). The only hint, '3+ recommended', lives in the schema, not the description.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, openWorldHint=true, non-idempotent, so the safety burden is partly carried structurally. The description adds real value with the performance warning ('SLOW'), but it never explains why the tool is flagged destructive, how long it may hold resources, or what the timeout actually aborts — all relevant for an annotated-destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, then the return value, then the caveat. Nothing is redundant and the warning is placed where an agent will see it before invoking.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-format detail is not required, and the description still summarizes it in one line. The only shortfall is that a destructive-flagged, long-running tool would benefit from a note on what it mutates or whether it requires a prior build.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with line, top_n, timeout, and file_path each documented in the schema itself. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the concrete mechanism (`lean --profile`) and the resource (a theorem at a given file/line), plus what comes back (per-line timing and categories). It is clearly distinct from sibling tools like lean_verify or lean_diagnostic_messages, though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is one genuine exclusion: 'avoid on theorems that already hit heartbeat limits.' That tells the agent a negative condition, but there is no positive routing guidance such as 'run lean_verify first' or when to prefer this over a plain build, so usage is only partially implied.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. The description adds that it includes the declaration, which is a behavioral detail beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, clear, no fluff. Every word is necessary and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values are covered. The description explains the core function and a key prerequisite. Could mention that it returns locations including declaration, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond the schema; it only mentions cursor positioning which relates to line/column but not in detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Find' with a clear resource 'all references to a symbol', explicitly includes 'including the declaration', and distinguishes from siblings like hover or goal tools by mentioning cursor positioning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a condition ('Position cursor at the symbol') but does not explicitly state when to use this tool versus alternatives like lean_local_search or lean_loogle, leaving the differentiation implicit.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations flag this as destructive, non-idempotent, and open-world, but the description says nothing about side effects, what state the snippet can affect, or why execution is considered destructive. The only added constraint is the self-contained imports requirement, which is already carried by the schema. For a code-execution tool with a destructive hint, this leaves the risk profile unexplained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no wasted words, and the core action is front-loaded before the input constraint. It is efficient, though extremely terse for a destructive operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the single parameter is fully documented in the schema. However, for a destructive code-execution tool, the definition omits where the code runs, what 'diagnostics' covers, and how it relates to sibling diagnostic tools, leaving meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema description coverage, so the schema already explains that code must be self-contained Lean with imports. The description restates that requirement rather than adding format, size, or content constraints beyond it. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource: run a Lean code snippet and return diagnostics. It is distinguishable from most siblings by the 'snippet in, diagnostics out' framing, though it does not explicitly contrast itself with lean_build or lean_multi_attempt.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The prerequisite 'Must include all imports' tells the agent how the input must be formed, but there is no explicit guidance on when to choose this over lean_build, lean_multi_attempt, or lean_diagnostic_messages. Usage is implied rather than stated.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and idempotent behavior. The description adds minimal context beyond that (e.g., 'expected type' vs full goal). No contradictions, but little extra value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single sentence with no wasted words. Information is front-loaded and easily parsed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While annotations and output schema exist, the description is minimal. It does not explain what the returned 'expected type' looks like or how it relates to the position, leaving some ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already documented. The description does not add any extra meaning or context about parameters, but given coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the expected type at a given position, using a specific verb and resource. However, it does not differentiate itself from the sibling tool 'lean_goal', which likely has a similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 like 'lean_goal'. The description lacks context on scenarios or limitations, leaving the agent to guess.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description usefully discloses scan scope (only the given file, not imports), which is behavior not visible in the schema. However, the annotations declare destructiveHint=true, readOnlyHint=false and idempotentHint=false for what reads like a pure verification operation, and the description never explains what is mutated or destroyed or what permissions are needed, leaving a notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste and the core action front-loaded, followed immediately by the scope caveat. The telegraphic phrasing ('Check theorem axioms') is slightly compressed but not ambiguous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the three parameters are fully documented in the schema. What is missing is any reconciliation of the destructive, non-idempotent annotation profile with a verification action, which matters for an agent deciding whether to call it casually.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description adds a bit by framing scan_source as an optional source scan and by stating the scan is limited to the given file. It does not clarify the absolute-path or fully-qualified-name requirements, but the schema already carries those.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and object: 'Check theorem axioms' plus an optional source scan. This is clearly not a build, search, or diagnostic tool, so it separates reasonably from siblings, though it never names an alternative or explicitly says it is the axiom/sorry-check tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The clause 'Only scans the given file, not imports' implies a scoping rule and hints that callers wanting dependency coverage must look elsewhere, but there is no explicit when-to-use or when-not-to-use guidance relative to lean_diagnostic_messages, lean_build, or other verification-adjacent siblings.

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