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

With no annotations, the description must disclose behavioral traits, but it only says 'try to automatically solve a goal.' It does not state whether this operation modifies the file, what happens on failure, any side effects, or whether it's a safe read-only attempt. The word 'try' implies a potential failure but gives no further detail.

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: a single purpose sentence followed by a simple args list. It front-loads the action and every sentence adds value. There is no unnecessary filler, making it appropriately sized for a simple tool.

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?

The description covers the core action and parameter semantics but lacks usage context and behavioral details. With no annotations and an output schema (not shown), the agent is left uncertain about side effects, failure modes, or how this compares to similar auto-solving tools. It is minimally adequate but has clear 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?

The input schema has 0% description coverage, but the description explicitly defines both parameters: file_path is the absolute path to the .agda file, and goal_id is the goal/hole number from agda_load output. This fully compensates for the schema gap and gives the agent all necessary parameter semantics.

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 with a specific verb+resource: 'automatically solve a goal.' It is distinct from many siblings like agda_case_split or agda_goal_type, but it doesn't explicitly differentiate itself from agda_solve_one or agda_auto_all, which likely have similar functions.

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 agda_refine, agda_solve_one, or agda_auto_all. It only mentions that goal_id comes from agda_load output, which is a prerequisite but not a usage guideline. It lacks any when-not-to-use or alternative tool references.

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?

With no annotations, the description must convey behavioral traits. It does disclose a key side effect: solving goals alters the goal state, requiring agda_load to refresh. It also uses 'Try' to indicate potential failure. However, it does not explain whether the operation is destructive, whether it modifies the file, or what happens when goals cannot be solved. This is moderate transparency but lacks comprehensive disclosure.

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 concise and well-structured. The first line states the core purpose, the second line gives a critical follow-up action, and the Args section cleanly documents the parameter. No redundant information; every sentence earns its place. It is front-loaded with the primary verb and resource.

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 tool with one parameter, no annotations, and an existing output schema, the description adequately covers the essential usage: what it does, the parameter, and the necessary follow-up. However, given the large sibling set (agda_auto, agda_solve_all), it would benefit from explicitly differentiating when to use this over alternatives. Still, the description is sufficient for basic invocation.

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?

The schema has 0% description coverage, so the description must compensate. It does so by providing a clear docstring for the only parameter: 'Absolute path to the .agda file.' This adds the crucial detail of being an absolute path, which the schema does not specify. The description effectively clarifies the parameter's meaning beyond the schema's minimal type/title info.

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 action: 'Try to automatically solve all visible goals.' This uses a specific verb ('solve') and resource ('visible goals'), and the naming convention (agda_auto_all) suggests it handles all goals, distinguishing it from siblings like agda_auto (likely single goal) and agda_solve_all. The purpose is unambiguous.

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 a use case: when you want to solve all visible goals. It also provides a crucial follow-up instruction ('Call agda_load afterwards to refresh goals'). However, it does not explicitly state when to use this tool over alternatives (e.g., agda_auto, agda_solve_all) or any scenarios where it should not be used. Thus, the usage guidance is implied but not fully explicit.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return value ('Returns the new clauses') but does not disclose whether the tool modifies the file, any side effects, error conditions, or prerequisites beyond the parameter hints. This is a significant gap for a tool that likely performs an edit to the Agda 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?

The description is concise, starting with a clear one-sentence purpose, followed by a structured Args list. Every sentence earns its place, with no redundant information 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?

The tool has a simple signature and an output schema, so return values don't need elaboration. The description provides sufficient parameter context and the crucial hint that goal_id comes from agda_load. However, for a tool likely to mutate an Agda file, the lack of any note about side effects or prerequisites reduces completeness slightly.

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?

The schema provides only parameter names with no descriptions, but the description adds meaningful context for all three parameters: file_path must be an absolute path, goal_id should come from agda_load output, and variable is the name to split on. This compensates well for the 0% schema coverage, though the variable explanation adds minimal extra value 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?

The description clearly states the action: 'Case split on a variable in a goal' and what it returns: 'Returns the new clauses.' This specific verb+resource distinguishes it from sibling tools like agda_intro or agda_refine, which serve different purposes.

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

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

The description implies usage: you would use this when you want to case split a variable in a goal. However, it does not explicitly state when to avoid it or mention alternative tools, leaving the usage context somewhat implied rather than fully articulated.

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?

With no annotations provided, the description carries the full burden of disclosing side effects, prerequisites, or error behavior. It only states 'Normalize' and mentions file_path is 'for scope,' adding minimal behavioral context beyond the tool's name.

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 highly concise, front-loaded with the primary verb, and includes a compact args list with examples. Every sentence serves a purpose, and there is no fluff.

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 two-parameter tool with an output schema, the description covers the core purpose and parameters. However, it lacks usage guidance and behavioral notes (e.g., when to prefer agda_compute_in_goal), leaving some context gaps given the large sibling set.

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 0%, so the description compensates by explaining both parameters: file_path is an absolute path for scope, and expr is shown with an example. This adds meaningful semantics beyond the bare schema, though more detail on expression syntax would improve it.

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 opens with 'Normalize (evaluate) an expression,' using a specific verb and resource. This clearly distinguishes agda_compute from siblings like agda_infer (type inference) and agda_definition (show definition), making the tool's purpose explicit.

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 given about when to use this tool versus alternatives like agda_compute_in_goal. The description explains what the tool does and lists parameters, but offers no context for selecting 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?

With no annotations, the description carries the full burden. It discloses that evaluation happens within a goal's context and mentions goal_id comes from agda_load output, but it does not explicitly state whether the operation is read-only or has side effects. It adds some behavioral context but is not a full safety/behavior profile.

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 concise and front-loaded, with a two-sentence explanation followed by a bulleted arg list. Every sentence adds value and there is no 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?

The description effectively covers the core purpose, the key distinction from agda_compute, and parameter semantics. Since an output schema exists, return values need no explanation. It is complete for an agent to select and invoke the tool, though it could mention error conditions or expression syntax.

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 0%, but the description fully compensates by explaining all parameters: file_path is an absolute path, goal_id is the goal/hole number from agda_load output, and expr is the expression to evaluate. This adds meaning beyond the bare schema property names.

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 the tool normalizes/evaluates an expression in a specific goal's context. The verb 'Normalize (evaluate)' is specific and the resource is well-defined, with explicit contrast to agda_compute.

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 explicitly names agda_compute as the alternative and explains the scope difference: 'Unlike agda_compute which works at top level, this evaluates within a goal's local context.' This provides clear context for when to use this tool, though it does not list exclusions or when-not-to-use scenarios.

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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Show all current unsolved constraints' without specifying whether this is a read-only operation, whether the file must be loaded first, or what happens if there are no constraints. It does not contradict annotations, but it is too sparse to fully inform the agent of behavioral traits.

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 very concise: a clear first sentence, a useful usage hint, and a parameter explanation. Every sentence earns its place, and the structure is efficient and easy to scan.

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 single-parameter tool, the description covers purpose, usage context, and parameter meaning. However, it omits important contextual details such as whether the file must be loaded via agda_load before this works, or what the output looks like if no constraints exist. Given the sibling tools include agda_load, this prerequisite is relevant and missing.

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?

The schema provides only a title 'File Path' with no description, so the description's explicit 'Absolute path to the .agda file' adds crucial meaning. This fully explains the one parameter, compensating for the 0% schema coverage, though it could state requirements like existing file or loaded file.

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 'Show' with a clear resource 'all current unsolved constraints', which unambiguously states the tool's function. It is distinct from sibling tools like agda_metas or agda_goal_type, and the purpose is immediately clear.

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 states it is 'Useful for debugging type errors or understanding what Agda is stuck on', providing clear context for when to use it. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only restates that it retrieves context, without mentioning prerequisites (e.g., file must be loaded), error behavior for invalid goal_id, or any side effects. This is insufficient for a tool with zero 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 concise and front-loaded, with a one-sentence purpose followed by a clear two-item parameter list. No redundant information or fluff; every sentence earns its place.

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 and the existence of an output schema, the description is largely complete for selection and invocation. It covers purpose and parameter semantics. The only gap is the lack of explicit usage guidance or prerequisites, but this is a minor omission for such a straightforward read 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?

The input schema has only parameter names with no descriptions (0% coverage). The description compensates fully: file_path is defined as 'Absolute path to the .agda file' and goal_id as 'The goal/hole number (from agda_load output)'. This adds meaningful semantics beyond the schema, enabling correct invocation.

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 function: 'Get the context (available bindings) at a specific goal/hole.' This uses a specific verb+resource and distinguishes it from sibling tools like agda_goal_type or agda_goal_info, which serve different purposes. The mention of 'from agda_load output' further clarifies the context of use.

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 context by noting that goal_id comes from agda_load output, indicating this tool is used after loading a file and identifying holes. However, it does not explicitly state when to choose this over alternatives like agda_goal_info or agda_goal_type, nor does it mention any exclusions. The context is clear but lacks explicit alternative 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without mentioning prerequisites (e.g., loaded file), side effects, or error conditions. The behavior beyond the basic action remains opaque.

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 exceptionally concise, with a single purpose sentence and a clean parameter list. Every word earns its place, and the structure is easy to parse.

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?

The tool is simple, but the description omits any environmental context such as the need for a loaded Agda file or how the definition result is returned. Since an output schema exists, return details are covered elsewhere, but prerequisites and usage context are absent.

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 0%, so the description must compensate. It adds useful semantics like 'Absolute path' and '1-based' for line/character, which goes beyond the schema titles, but it does not fully elaborate on how these positions relate to the Agda buffer.

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 'Go to the definition of a symbol at a position,' which is a specific verb+resource action. It distinguishes itself from sibling tools like agda_hover or agda_infer, which serve different purposes.

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

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

No explicit when/when-not guidance is provided, nor are alternatives mentioned. The intended use is implied by the description and name, but the description lacks any contrast with sibling tools or exclusions.

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?

With no annotations, the description carries the burden of disclosure. It reveals that the tool returns a normalized expression and that subsequent state changes require agda_load, which is useful. However, it does not mention potential side effects, error behavior, or whether it modifies the file, leaving some behavioral aspects opaque.

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 compact and well-structured. It opens with a clear purpose, then a brief differentiating note, a follow-up instruction, and a clean parameter list. Every sentence contributes value, and the length is appropriate for the tool's complexity.

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?

The description provides enough context for an agent to select and use the tool: it explains the difference from agda_give, the need to refresh with agda_load, and the parameter semantics. Since an output schema exists, return values need not be explained. Missing details like prerequisites or failure modes are minor given the tool's simplicity.

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?

The schema has zero description coverage, but the description provides meaningful explanations for all three parameters: file_path is an absolute .agda path, goal_id comes from agda_load output, and expr is the fill expression. This compensates well for the schema's lack of detail, though it could include more constraints (e.g., expression input format).

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 fills a goal/hole with an elaborated solution, using a specific verb and resource. It explicitly distinguishes itself from the sibling tool agda_give by noting it returns the fully elaborated (normalized) expression, which eliminates ambiguity.

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 contrasts with agda_give, indicating when this tool is preferred (when elaborated/normalized output is desired). It also advises calling agda_load afterwards to refresh goals, which is actionable guidance. However, it does not explicitly mention when not to use it or alternatives beyond agda_give.

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?

With no annotations, the description carries the burden of disclosure. It does state that Agda will check the expression and, if correct, replace the hole in the source file, which conveys a side-effecting operation. However, it omits error behavior when the expression is incorrect and does not mention any permissions or backup/recovery aspects.

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 well-structured and concise: a single-purpose opening line, a short behavioral clause, and a straightforward argument list. Every sentence contributes without redundancy, making it easy for an agent to parse quickly.

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?

The tool modifies source code and has a follow-up action (agda_load), but the description does not cover failure modes or the output schema (which exists). It is adequate for a simple tool but leaves gaps around what happens if the expression is invalid or if the goal_id is stale.

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 0%, so the description must compensate. It lists each parameter with a brief but meaningful explanation: file_path is an absolute path, goal_id comes from agda_load output, and expr is the expression to fill. This adds value over the bare schema, though it could be more detailed about expression syntax or valid goal_id ranges.

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 opens with a specific verb and resource: 'Fill a goal/hole with a complete solution.' This clearly distinguishes it from sibling tools like agda_refine or agda_intro, which perform different actions on goals. The mention of 'complete solution' further clarifies its 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?

The description implies usage by stating 'Call agda_load afterwards to refresh goals,' which gives a workflow context. However, it does not explicitly state when to prefer this tool over alternatives like agda_elaborate_give or agda_refine, nor does it provide any exclusions or conditions.

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?

No annotations are present, so the description carries the full burden. It clearly implies a read-only operation ('Get'), and it adds useful context that goal_id comes from agda_load output, indicating a dependency. However, it does not describe error behavior, prerequisites, or relationship to other inspection tools.

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: a one-sentence summary plus an args list. Every word earns its place, with no fluff or redundant phrasing.

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 (2 params) and the presence of an output schema, the description adequately covers the essentials. It explains what the tool does and defines both parameters. It could be more complete by mentioning how it differs from similar goal-inspection tools, but the core usage is well covered.

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 0%, so the description must compensate. It adds meaning to both parameters: file_path is 'Absolute path to the .agda file' and goal_id is 'goal/hole number (from agda_load output)', which goes beyond the bare schema titles and types.

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 'Get' and names the resource ('type and context of a specific goal/hole'), making the core purpose clear. However, sibling tools like agda_goal_type, agda_context, and agda_goal_type_context_infer appear to overlap, and the description does not differentiate this tool from them.

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. Given the large set of sibling tools with similar goals, the absence of usage context or exclusions makes it hard for an agent to select this tool reliably.

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?

No annotations are present, so the description carries the burden of behavioral disclosure. It does mention that goal_id comes from 'agda_load output', implying a prerequisite on loading the file, and clarifies that the result excludes context. However, it does not explicitly confirm that this is a read-only operation, nor does it describe behavior on invalid inputs 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?

The description is extremely concise and well-structured: a single one-line summary followed by a clean Args list. Every sentence earns its place, with no redundant or filler 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?

Since an output schema exists, the description need not explain return values. It covers the essential purpose and parameter semantics, and the hint about agda_load output provides workflow context. It lacks explicit statements about when the file must be loaded or error handling, but for a simple query tool, this is largely 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 descriptions are absent (0% coverage), so the Args section must compensate. It adds valuable meaning: file_path is specified as an 'Absolute path to the .agda file', and goal_id is defined as 'The goal/hole number (from agda_load output)', linking to a prerequisite and clarifying the expected input format beyond the bare schema types.

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 action: 'Get the type of a specific goal/hole'. The parenthetical '(without context)' distinguishes it from sibling tools like agda_goal_type_context_infer or agda_goal_type_context_check, making the purpose unambiguous.

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 explicit guidance on when to use this tool versus alternatives. The phrase 'without context' hints at a scoping choice but does not name sibling tools or provide any exclusion criteria. An agent would not know whether to prefer this over agda_goal_info or agda_goal_type_context_infer.

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?

With no annotations, the description carries the full burden of disclosing behavioral traits. It does not mention side effects, whether the operation is read-only, output format, error behavior, or dependencies on prior calls like agda_load. The phrase 'check an expression against the goal type' is ambiguous about what checking entails.

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 concise and well-structured: a single-sentence purpose followed by a clear parameter list. Every sentence adds value without 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?

The description covers purpose and parameters but lacks usage context and behavioral details. An output schema exists which may explain return values, but the description itself does not clarify when to use this tool over similar siblings, making it only partially complete for a tool in a large family.

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?

Despite 0% schema description coverage, the Args section explains each parameter: file_path is 'Absolute path to the .agda file', goal_id is 'The goal/hole number (from agda_load output)', and expr is 'Expression to check against the goal type'. These explanations add meaning beyond the raw schema properties.

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 'Get goal type, context, and check an expression against the goal type,' which specifies a concrete action on a concrete resource. It distinguishes from sibling tools like agda_goal_type and agda_context by combining these operations with an expression check, though it does not explicitly name alternatives.

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

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

No guidance is given on when to use this tool versus alternatives. The description merely states the action and parameters without explaining scenarios, exclusions, or comparisons to sibling tools such as agda_goal_type_context_infer or agda_infer_in_goal.

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?

With no annotations, the description must carry the full burden of behavioral disclosure, but it only states what information the tool returns. It fails to mention side effects, permission requirements, error behavior, or any operational context beyond parameter descriptions. This leaves the agent uncertain about the tool's behavior in practice.

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 appropriately short and front-loaded with the main purpose, followed by a clean Args list. Every sentence contributes directly to understanding the tool, with no filler 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?

Although an output schema exists, the description lacks crucial usage context. It does not explain when to choose this tool over closely related siblings, nor does it mention prerequisites or error scenarios. For a tool with three parameters and a large sibling set, this is only minimally 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?

The description adds meaningful semantic context to all three parameters despite the 0% schema description coverage. It specifies 'absolute path' for file_path, connects goal_id to 'agda_load output', and clarifies expr as 'Expression whose type to infer in this goal's context.' These are concise but useful clarifications that go beyond the bare 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?

The description clearly states the tool's action: 'Get goal type, context, and the inferred type of an expression,' which specifies a precise combination of information. However, it does not explicitly distinguish this from sibling tools like 'agda_goal_type_context_check' or 'agda_infer_in_goal', so it falls short of a perfect score.

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

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 include prerequisites (e.g., needing to call agda_load first), exclusions, or recommended scenarios. The only contextual hint is 'goal_id from agda_load output', but this is presented as a parameter detail, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that Agda will generate the type signature and describes the partial application format. However, it does not disclose potential side effects (e.g., whether it modifies the file), prerequisites (e.g., a running Agda process), or any error conditions. This adds some transparency but leaves gaps.

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 concise and well-structured, with a clear one-sentence purpose, followed by a brief explanation of the expression format, and then a straightforward list of arguments. No unnecessary words or repetition, making it easy to parse.

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?

The tool has a moderate complexity level and an output schema (which likely documents return values). The description covers the main usage pattern and parameter semantics, making it complete enough for most use cases. It could mention edge cases or what happens when the helper already exists, but the output schema and the provided details are sufficient for an agent to invoke the tool correctly.

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?

The input schema has no parameter descriptions (0% coverage), so the description fully compensates by explaining each argument: file_path (absolute path to the .agda file), goal_id (goal/hole number from agda_load output), and expr (partial application like 'helper x y'). It also clarifies the default behavior of expr, which adds significant 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?

The description clearly states the tool's purpose: 'Generate a helper function type signature for a goal.' It specifies a concrete verb ('Generate') and resource ('helper function type signature'), and explains the partial application expression format. This distinguishes it from sibling tools like agda_goal_type or agda_infer, which serve different purposes.

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

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

The description provides implicit usage guidance by explaining how the 'expr' parameter works and the default behavior when empty ('If empty, uses whatever is in the goal'). However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, leaving the agent to infer the appropriate context from the tool's name and 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?

No annotations are provided, so the description carries the full burden. It describes what info is fetched but does not disclose behavioral traits such as whether the position must be exact, how errors are handled (e.g., symbol not found), or any side effects (though likely none). The description is too minimal to fully inform an agent about runtime behavior.

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 concise and well-structured. The opening sentence states the purpose, followed by a clear Args list. Every sentence earns its place, and there is no fluff or repetition.

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?

The tool is simple and has an output schema (per context signals), so return values need not be explained. The description covers purpose and parameters adequately. However, it lacks any mention of usage context or edge cases (e.g., file not loaded, invalid position), making it slightly less complete for a tool with no annotations.

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?

The description adds substantial meaning beyond the bare schema. It explains each parameter in the Args section: file_path is an absolute path, line is 1-based, character is 1-based. This is critical for correct invocation and goes beyond the schema which only provides titles and types. Schema description coverage is 0%, but the description fully compensates.

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 function: 'Get type/definition info for a symbol at a position.' This is a specific verb+resource combination that distinguishes it from sibling tools like agda_definition (which likely fetches a definition by name) and agda_infer (type inference). The scope is precise.

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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., file must be loaded) or contrast with sibling tools that might overlap in purpose. The context of sibling tools suggests some possible overlap, but the description offers no differentiation.

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?

With no annotations provided, the description carries the full burden of disclosing behavior. It only states the basic action and param meanings, but does not mention what the tool returns, whether it requires the file to be loaded first, or how it handles errors. It lacks details like side effects, permissions, or output context.

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 compact, with a clear purpose statement and an args list that maps directly to the schema. Every sentence serves a function—no filler 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 tool's low-to-moderate complexity, the presence of an output schema, and the absence of annotations, the description covers the essential context: purpose and parameters. It signals the 'loaded file' prerequisite, which is important. However, it could be more explicit about whether the file must be loaded via agda_load first and what happens if not, but the description is largely complete for its simplicity.

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?

The input schema provides only names ('file_path', 'expr') with 0% description coverage, so the description must compensate. It does this effectively by specifying 'file_path' as an absolute path for scope and giving concrete examples for 'expr'. This adds meaningful context beyond the schema, though it could be more explicit about the exact syntax expected.

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 a specific action ('Infer the type of an expression') on a specific resource ('in the context of a loaded file'), which differentiates it from sibling tools like agda_compute or agda_goal_type. The scope is well-defined, and examples for expr reinforce its 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?

The description provides clear context: this tool is for type inference in the context of a loaded file, which implies a prerequisite that the file is loaded. It does not explicitly name alternatives or exclusions, but the context is sufficient to distinguish it from siblings like agda_infer_in_goal.

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?

No annotations are provided, so the description carries the burden. It discloses that it works in a goal's local context with locally-bound variables, and contrasts with top-level inference. However, it doesn't mention prerequisites like needing an active agda_load or handling invalid goal IDs, limiting behavioral transparency.

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 concise and well-structured: a clear opening sentence, one comparative sentence for differentiation, and a compact Args list. No fluff.

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 typed expression tool with 3 fully documented parameters, an output schema, and clear differentiation among many siblings, the description is quite complete. It could mention preconditions (e.g., file loaded via agda_load), but the goal_id reference hints at it.

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 properties lack descriptions (0% coverage), but the description's Args section explains each parameter: file_path as absolute path, goal_id from agda_load output, and expr to type-check. This fully compensates for the schema gap.

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 'Infer the type of an expression in the context of a specific goal.' This is a specific verb+resource+context, and it explicitly contrasts with agda_infer, distinguishing it from a sibling 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?

It explicitly says 'Unlike agda_infer which works at top level, this infers within a goal's local context (with access to locally-bound variables).' This names the alternative and clarifies the appropriate context.

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?

With no annotations, the description carries the transparency burden. It discloses that the tool 'tries' (may fail) and that goals need refreshing afterward, implying a state change. But it does not mention file modification, required preconditions beyond the goal_id source, or failure behavior.

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 brief and front-loaded with the core purpose. Every sentence contributes value, including the follow-up load instruction and the parameter details. 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?

The tool has only two required parameters and an output schema, so the description covers invocation essentials well. It includes the key workflow detail (call agda_load after). It loses a point because it does not mention when to choose this over sibling tools, especially agda_refine_or_intro.

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 0%, but the description compensates fully: file_path is defined as 'Absolute path to the .agda file' and goal_id as 'The goal/hole number (from agda_load output)'. This adds concrete meaning that the schema's names alone do not convey.

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 action ('Introduce a constructor or lambda abstraction in a goal') and elaborates with 'Tries to fill the hole with an appropriate constructor or lambda.' This clearly distinguishes the tool from siblings like agda_case_split or agda_load.

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 workflow instruction: 'Call agda_load afterwards to refresh goals.' However, it does not explicitly say when to prefer this over related tools such as agda_refine_or_intro, agda_auto, or agda_give, so alternatives are not addressed.

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?

Since no annotations are provided, the description carries the full burden. It discloses that the tool type-checks, returns diagnostics, and requires a specific call order, including a refresh pattern after edits. It does not mention potential side effects, but for a load/type-check tool, this is arguably sufficient and adds substantial context beyond the schema.

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 concise and front-loaded: it states the main purpose in the first sentence, then gives usage requirements and argument details. Each sentence earns its place with no redundant or filler 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?

Given the tool's simplicity (one parameter) and the existence of an output schema, the description covers the essential usage context: what it does, what it returns, and the required call/refresh pattern. It is complete for an AI agent to correctly invoke the 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?

With 0% schema description coverage, the description compensates by defining `file_path` as 'Absolute path to the .agda file'. This adds critical semantics (absolute path and file extension) that the raw schema lacks, making it clear to the agent what value to provide.

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 ('Load and type-check') and resource ('an Agda file'), and explicitly mentions the outputs ('goals, errors, and warnings'). This clearly distinguishes it from sibling tools that perform more targeted operations like case splitting or hovering, establishing it as the foundational entry point.

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 explicit usage guidance: 'This must be called before other commands' and 'Call again after edits to refresh.' This tells the agent exactly when to use the tool and when to re-invoke it, which is essential for the interactive Agda workflow.

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?

With no annotations, the description must carry the behavioral burden. 'Show' implies a read-only operation, and adding 'all open' clarifies scope, but it does not disclose potential side effects, dependencies (e.g., file must be loaded), or error behavior. The description adds some context but lacks explicit safety or prerequisite notes.

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: a single lead sentence plus a clearly formatted Args block. Every element earns its place, and the key 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?

The tool is simple (one parameter, no nested objects) and has an output schema, so return values need not be described. The description covers core behavior and parameter meaning. It falls short only in usage guidance, but that is already penalized in dimension 2, so overall completeness is strong.

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?

Although schema coverage is 0%, the description compensates by defining file_path as 'Absolute path to the .agda file', adding meaning beyond the schema's bare string type. It specifies absolute path and file extension, which is valuable for correct invocation.

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 ('Show') and resource ('all open meta-variables (goals) and their types'), clearly identifying the tool's function. It distinguishes from siblings like agda_goal_type (single goal) and agda_context (context) by emphasizing 'all' metas.

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 the many siblings (e.g., agda_goal_type, agda_constraints, agda_context). The description states what it does but not in which situations it is the preferred choice or if any prerequisites exist (like loading the file first).

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that the tool lists top-level names but does not describe potential side effects, error conditions, or assumptions (e.g., file path validity, module loading state). Given the simple read-only nature, a 2 reflects the lack of explicit behavioral context beyond the literal action.

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 concise and front-loaded with the primary action. The Args block is well-structured and uses an efficient format with examples. 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?

For a simple two-parameter tool, the description covers the core usage. However, it lacks contextual information such as whether the module must be already loaded, what 'top-level names' includes, and how errors are handled. The presence of an output schema reduces the need to describe return values, but the gaps in usage context bring it to a minimum viable score.

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 0%, but the description compensates by defining both parameters: file_path as absolute path to the .agda file and module_name with examples. This adds meaning beyond the raw parameter names and helps the agent construct correct arguments.

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 function with a specific verb ('List') and resource ('top-level names exported by a module'). It is unambiguous, though it does not explicitly differentiate from the sibling tool agda_module_contents_goal, relying on name similarity to signal context.

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 alternatives. The description provides parameter explanations but no context on prerequisites (e.g., whether the module must be loaded in Agda) or exclusions. The sibling tool agda_module_contents_goal suggests a goal-context variant, but this is not 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic listing operation and goal context, but does not mention whether the module must be already loaded, how the goal context affects results, or possible error conditions. It also does not clarify whether this is a read-only operation, though 'List' suggests so.

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 compact and well-structured: a one-sentence purpose statement followed by a clean Args list. Each parameter has a concise, useful one-line explanation, and no unnecessary information is included.

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?

The tool has three parameters, no annotations, and an output schema. The description covers the core purpose and parameters adequately, but given the nuanced goal-context nature of Agda tools, it could benefit from explicit guidance on prerequisites (e.g., requiring a prior agda_load) or how the goal context changes results. The output schema helps, but overall the description is only minimally complete.

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?

Despite 0% schema description coverage, the description provides meaningful explanations for all three parameters: file_path is absolute, goal_id comes from agda_load output, and module_name is the module/record to inspect. This adds practical value beyond the bare schema and helps an agent provide valid arguments.

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 lists module contents specifically in the context of a goal, with a distinct goal_id parameter. This distinguishes it from the sibling tool agda_module_contents, which presumably operates without goal context. The verb 'List' and resource 'contents of a module' are specific and unambiguous.

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 phrase 'in the context of a goal' implies this tool is for goal-specific exploration, but the description does not explicitly state when to choose this over agda_module_contents or other goal tools. No alternatives or exclusions are mentioned, leaving usage largely inferred rather than explicit.

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?

No annotations exist, so the description must elucidate behavior. It mentions subgoal creation and empty expr behavior, and the need to reload. But it omits failure modes, file modification details, and permission/state effects.

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 compact and well-structured: a one-line summary, key caveats, and an Args list. No redundant statements.

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?

The description covers core behavior, optional expression, and the post-requisite of calling agda_load. With an output schema present, return values are not needed. It lacks cross-referencing to sibling tools, which would help an agent choose between refine, give, and auto.

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?

The description provides a dedicated Args section explaining all three parameters, including critical context (goal_id comes from agda_load output, expr can be empty). This far exceeds the bare input schema, compensating fully for the 0% schema coverage.

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 opening line uses a specific verb ('refine') and resource ('goal'), and notes that it may create subgoals, which distinguishes it from sibling tools like agda_give or agda_auto. This clearly states what the tool does.

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 clearly describes the tool's behavior and instructs to call agda_load afterward to refresh goals, giving context for sequencing. However, it does not explicitly state when to prefer this over siblings like agda_give or agda_refine_or_intro.

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?

With no annotations, the description carries the full burden. It discloses the decision process and the need to call agda_load afterwards. However, it does not mention potential failure modes, side effects on the file, or any required state beyond the goal_id.

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 reasonably concise and front-loaded with the core purpose. The Args section is clearly structured and each line adds value. It could be slightly tighter, but no extraneous filler is present.

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 combined behavior and no annotations, the description adequately covers prerequisites (goal_id from agda_load), the decision logic, and a required post-step. An output schema exists, so return values need not be described. It lacks notes on failure cases, but overall it is complete for typical use.

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 0%, but the description thoroughly explains all three parameters. It provides the exact meaning of file_path, goal_id (from agda_load output), and adds crucial detail that expr can be empty for intro, which is not evident from 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?

The description clearly states 'Refine or introduce in a goal' with a specific verb and resource. It also distinguishes from siblings by noting it 'Combines refine and intro', directly referencing the two sibling tools it merges.

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 the auto-selection behavior (refine if expr given, otherwise intro), which implies when the tool would be used, and mentions the follow-up 'Call agda_load afterwards'. However, it does not explicitly state when to choose this over the individual agda_refine or agda_intro tools, or provide exclusion 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?

With no annotations, the description carries the burden of disclosing behavior. It clearly indicates a read-only search operation (no side effects), scoped to a specific file via 'file_path.' It does not describe return format, but an output schema is present, so that is not required. The description is transparent enough for a search 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?

The description is concise and well-structured. It opens with a clear action statement, adds a brief utility note, and then provides a clean Args list. No unnecessary repetition or filler. Every sentence contributes 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?

Given the simple two-parameter schema and the presence of an output schema, the description is complete. It specifies the purpose, the parameters, and the intended use case. There are no missing edge cases or prerequisites for this search tool. It provides enough context for an agent to select and invoke it correctly.

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?

The description includes an 'Args' section that explains each parameter beyond the bare schema. It specifies that 'file_path' is the 'Absolute path to the .agda file' and 'query' is 'Space-separated names to search for in types.' This fully compensates for the schema's 0% coverage and adds meaningful semantic 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 clearly states a specific action: 'Search for definitions whose type mentions the given names.' It identifies the resource (definitions in .agda files) and distinguishes from sibling tools like agda_definition (which gives a specific definition) and agda_infer (which infers types). The addition 'Useful for finding relevant lemmas, functions, or constructors' further clarifies its 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?

The description provides clear context on when to use the tool: it is 'useful for finding relevant lemmas, functions, or constructors.' This implies it is a search/discovery tool, distinguishing it from other tools that operate on a current goal or expression. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.

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?

With no annotations, the description carries the full burden for behavioral transparency. It mentions the need to refresh after solving, but does not disclose what 'solve' does to the file, whether it can partially succeed, or any side effects. This leaves significant ambiguity.

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 appropriately sized, with the core purpose in the first sentence, a usage note in the second, and a concise parameter definition. No wasted words.

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?

The description covers the core action and a follow-up step, but does not explain edge cases such as when unification does not determine solutions, or the effect on goals in the buffer. Given the output schema exists, return values need not be explained, but the tool's behavior warrants more detail for an agent to use correctly.

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?

The description includes an Args section that adds meaning beyond the schema: 'Absolute path to the .agda file' specifies the format and purpose, which the schema's 'File Path' title does not. With one parameter, this is sufficient compensation for the schema's lack of description.

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 the tool's function: 'Solve all goals whose solutions have been determined by unification.' This specific verb-object relationship and the condition distinguish it from sibling tools like agda_solve_one and agda_auto.

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 the follow-up action 'Call agda_load afterwards to refresh goals,' but does not explicitly state when to use this tool versus alternatives. It implies usage for multiple goals with determined solutions, but lacks explicit exclusions or comparisons to 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?

No annotations are provided, so the description carries the burden. It discloses that the goal state changes (requiring agda_load) and reveals a limitation (only works on fully instantiated goals). It stops short of describing failure behavior or file modifications, but adds meaningful context beyond the schema.

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 compact and well-structured: one sentence for purpose, two lines for conditions/action, and a simple args list. 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?

The tool is simple with two parameters, and the description covers purpose, conditions, and parameter semantics. Since an output schema exists, return value details are unnecessary. The reload instruction and unification condition complete the picture for 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?

The input schema has 0% description coverage, but the 'Args' section explains file_path as an absolute path and goal_id as the goal number from agda_load output. This provides essential meaning that the schema lacks.

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 solves a single goal, with the specific condition that the solution is determined by unification. This distinguishes it from siblings like agda_solve_all and other goal-manipulation 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?

It provides an explicit precondition ('Only works if the goal has been fully instantiated') and a follow-up action ('Call agda_load afterwards to refresh goals'). While it does not name alternative tools, the condition gives clear context for when to use this tool.

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?

With no annotations, the description carries the burden of behavioral disclosure. 'Explain' strongly implies a read-only operation, but the description does not explicitly state that it does not modify files or whether it requires a loaded project context. It provides minimal but acceptable transparency.

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, front-loaded with the purpose, and uses a clear Arg list for parameters. Every sentence earns its place with no 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?

The tool is relatively simple and the output schema exists, so return values are covered. However, the description does not mention any preconditions (e.g., file must exist, project must be loaded) or differentiate from similar sibling tools, leaving some contextual gaps for an agent deciding to invoke it.

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?

Despite the schema having no parameter descriptions (0% coverage), the description fully explains both parameters: file_path is the absolute path to the .agda file, and name is the symbol to look up with concrete examples. This fully compensates for the schema gap.

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 ('Explain') and resource ('where a name is brought into scope'), clearly identifying the tool's function. It also distinguishes from siblings like agda_definition and agda_why_in_scope_goal by focusing on scope introduction rather than definitions or goal-specific context.

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 through its purpose and parameter examples, but it does not explicitly state when to use this tool over alternatives like agda_why_in_scope_goal or any prerequisites (e.g., file must be loaded). This is adequate but lacks explicit 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?

No annotations are provided, so the description carries the transparency burden. It discloses the key behavior (goal-local scope lookup) and the dependency on prior agda_load via the goal_id parameter. The verb 'Explain' implies a read-only operation, though it does not explicitly state non-mutation or error behavior.

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 compact argument list. It front-loads the purpose and comparison, then enumerates parameters without redundancy. Every sentence earns its place.

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?

The tool is a focused lookup with an output schema, so returning value details are not required. The description covers purpose, usage context, and prerequisites, making it adequate for an agent to invoke correctly. It could mention explicit exclusions against other sibling tools, but the comparison to agda_why_in_scope provides sufficient contextual guidance.

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 0%, so the description must compensate. It provides concise descriptions for all three parameters (file_path, goal_id, name), adding meaning beyond the bare schema titles. The descriptions are sufficient for an agent to populate the arguments correctly.

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 and resource: 'Explain where a name is brought into scope, in the context of a goal.' It clearly differentiates from its sibling agda_why_in_scope by noting access to the goal's local 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?

It provides an explicit comparison: 'Like agda_why_in_scope but with access to the goal's local scope,' which tells the agent when to prefer this tool over the base version. It also notes the prerequisite that goal_id comes from agda_load output.

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