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

With no annotations, the description carries the full burden, and it does disclose the shape of the result (definition, parameters, internal logic). However it says nothing about failure modes (missing file, unknown AOI name), permissions, or whether the file is read from disk versus an already-loaded project.

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 lead sentence is front-loaded and free of padding. The Args block largely duplicates the input schema, which is mild waste but not enough to hurt readability.

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

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

An output schema exists, so return values need not be explained, and the tool is a simple two-required-parameter read. What is missing is the load-state prerequisite and the list-vs-single relationship to get_aois, leaving the agent to guess the correct call sequence.

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. The Args section only restates the parameter names: 'l5x_path: Path to a .l5x file' adds the file type, but 'aoi_name: AOI name' is pure tautology, and neither explains format, expected location, or case sensitivity.

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

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

States a specific verb and resource ('Get an Add-On Instruction definition') and adds scope detail ('with parameters and internal logic'). It reasonably distinguishes the single-AOI fetch from the sibling get_aois, though it never names that sibling explicitly.

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

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

No guidance on when to use this versus get_aois, get_routine, or search_logic. There is no mention of prerequisites such as whether the .l5x must be loaded first (load_project exists as a sibling), so the agent must infer usage from the name alone.

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

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

With no annotations, the description carries the full burden, and it partially meets it: "List all" implies a non-mutating read of a local file, so no side effects are suggested. However, it says nothing about failure modes (missing/invalid .l5x path), size of result sets, or any file-access requirements.

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

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

Two short sentences with the purpose front-loaded and zero filler; the Args block is compact. Slight redundancy in re-declaring the parameter type already visible in the schema, but nothing wasteful.

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

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

An output schema exists, so return structure need not be described, and this is a simple one-parameter lister. The only real gap is the absence of any prerequisite or error context, which keeps it just short of fully 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?

There is a single parameter with 0% schema description coverage, and the description only restates it as "Path to a .l5x file." That adds a small amount of meaning (file type) but no format, path style, or validation detail, so it only partly 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?

States a specific verb ("List all") and resource ("Add-On Instructions in an L5X project"), which cleanly separates it from unrelated siblings like get_routines or get_tags. It does not explicitly contrast itself with the singular get_aoi sibling, but the plural/"all" scoping makes the distinction inferable.

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 gives no when-to-use guidance, no mention of the singular alternative get_aoi for fetching one instruction, and no prerequisite information (e.g., whether load_project must run first). The agent must infer the usage context entirely from the tool name.

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

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

With no annotations present, the description carries the full burden and does disclose a genuinely non-obvious behavioral trait: ladder logic is returned as compact NeutralText with rung comments rather than raw XML. It omits error behavior (e.g., routine not found) and permission/file-access expectations, keeping it short of a 5.

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 core purpose is front-loaded in the first line, and the NeutralText explanation earns its place by preempting confusion about the return format. The XML-comparison example is slightly verbose but justifies the design rather than padding.

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

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

An output schema exists, so return values need not be explained, and all three required parameters are at least named in the description. The main gaps are error handling and routing versus sibling read tools, which are minor for a simple getter.

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 lists all three parameters and clarifies l5x_path is a path to a .l5x file and program is the containing program. However, it adds no format, constraint, or naming-convention detail beyond the parameter names themselves.

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?

Specific verb ('Get') plus resource ('routine') with an explicit statement of what is returned: NeutralText for ladder, raw code for Structured Text. It does not explicitly distinguish itself from the sibling get_routines (plural), leaving the single-vs-list distinction to be inferred from the name.

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 on when to use this tool versus get_routines, search_logic, or get_aoi. The description never states the conditions or context in which retrieving a single routine is the right call.

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. 'List routines ... with type and size info' implies a read-only enumeration and hints at the returned content, but it does not state that the operation is non-mutating, whether the file is read from disk, or any performance/large-project caveats.

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

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

Front-loaded with the purpose sentence, then a compact Args block limited to the two parameters. No filler sentences, though the Args duplication of the schema adds little formatting 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?

An output schema exists, so return values need not be explained, and both parameters are documented. What is missing is differentiation from the sibling get_routine and any note on project/file prerequisites, leaving an agent to infer the list-vs-single choice.

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, and it does: l5x_path is described as the path to a .l5x file and program is described as a name filter whose empty value returns routines across all programs — the latter adds meaning beyond the bare schema default.

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

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

States a specific verb and resource ('List routines in an L5X project') plus the content returned ('type and size info'). It is distinguishable from the singular get_routine by the plural 'List', but the description never explicitly contrasts the two siblings.

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 on when to use this versus get_routine (single routine), get_udts, or get_tags. The only conditional behavior given is the 'program' empty-string filter, which is parameter behavior rather than usage 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 behavioral burden, and it discloses one real trait: the lookup searches all scopes rather than one. It says nothing about what happens when the tag is missing, permission/file-access requirements, or case sensitivity, which are the gaps an agent would care about for a lookup 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 single-line purpose is front-loaded and the whole entry is short with no filler. The 'Args:' block duplicates structure already carried by the input schema, which is mildly redundant but not wasteful.

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

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

An output schema exists, so return values need not be explained, and the purpose plus both params are covered. What is missing for a file-path-driven lookup tool is error behavior (unknown tag) and any link to load_project, leaving the agent to guess at the call sequence.

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 is the only documentation, and it does name both required params. However, 'l5x_path: Path to a .l5x file' only restates the parameter name plus file type, while only tag_name ('searches all scopes') adds genuine meaning, so it compensates only partially.

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 and resource ('Get details for a specific tag by name'), which clearly separates it from the plural sibling get_tags and from get_udt/get_aoi. It never names those siblings explicitly, so the differentiation is inferable rather than stated.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of prerequisites such as whether load_project must run first even though that sibling exists in the family. The only usage-ish hint is 'searches all scopes', which is behavioral rather than routing 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 full burden. 'List' implies a read-only operation and the scope semantics are explained, but nothing is said about file access requirements, behavior on large projects, or how scope interacts with data_type filtering. Adequate but not rich.

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?

One summary sentence followed by a compact Args block — front-loaded and free of filler. Slightly mechanical but every line 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?

An output schema exists, so return values need no explanation, and all three parameters are documented. The only real gap is routing guidance relative to the singular get_tag sibling, which is a minor omission for a listing tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: l5x_path is identified as a path to a .l5x file, scope is defined with its accepted values ('controller', program name, empty for all), and data_type is illustrated with concrete examples. This meaningfully exceeds 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?

States a specific verb and resource ('List tags') scoped to an L5X project, and the filtering dimensions are named. It does not explicitly distinguish itself from the singular sibling get_tag or from get_udts/get_aois, but the plural-list framing makes the distinction inferable.

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 says filters are 'optional' and defines scope values, which implies when to use each filter, but it never names an alternative (e.g. get_tag for a single tag) or states when not to use this tool. Usage is implied rather than stated.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It only implies read-only via the word "Get" and notes that member details are included; it says nothing about whether the .l5x must be pre-loaded via `load_project`, file-access constraints, or size/performance characteristics of returning all UDTs.

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

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

Two lines of prose plus two parameter lines — lean and front-loaded with the action. The docstring-style "Args:" block is a mild stylistic artifact but wastes no 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?

An output schema exists, so return-value explanation is not required, and both parameters are covered. What is missing is the boundary against `get_udts` and any note on how `l5x_path` relates to the `load_project` sibling — exactly the context an agent needs before invoking.

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, and it does document both parameters: `l5x_path` as a path to a .l5x file and `udt_name` with the non-obvious empty-string semantics (returns all UDTs). It does not clarify the expected path form (absolute vs relative) or whether the file must already be loaded.

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 verb+resource ("Get UDT definition(s) with member details") is stated, but the plural "definition(s)" collides directly with the sibling `get_udts`, which appears to be the list-all variant. Nothing in the description lets an agent tell which of the two to call for which case.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as `get_udts`. The only conditional given ("If empty, returns all UDTs") is parameter behavior, not tool-selection guidance, and it arguably makes this tool overlap with its sibling.

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 does disclose one meaningful behavioral trait — that only names are returned, not full type definitions — which is the key thing an agent needs to know. However it says nothing about whether the call is read-only (implied by 'List'), error behavior on a bad path, or output shape, though an output schema exists.

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 purpose sentence is front-loaded and wastes no words. The Args block is slightly redundant boilerplate for a single parameter, but it is where the only parameter documentation lives, so it 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?

For a single-parameter, read-oriented listing tool with an output schema present, the definition covers what the tool returns (names) and how to invoke it (file path). The main remaining gap is the relationship to load_project and whether the L5X must be pre-loaded, which is left to inference.

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, and it does: it documents the single parameter as 'Path to a .l5x file', which conveys the expected file type and format that the bare string schema does not. It stops short of stating whether the path must be absolute or whether the file must already be loaded.

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

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

States a specific verb (List) and resource (User Defined Type names in an L5X project), with the 'names' scope explicitly narrowing it to identifiers only. This naturally distinguishes it from the singular sibling get_udt, which an agent can infer returns details for one type without opening its schema.

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

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

Usage is only implied: listing UDT names is the obvious precursor to calling get_udt for a specific type, and it requires an already-available .l5x path. There is no explicit when-to-use statement, no exclusion, and no mention of prerequisites such as whether the project must be loaded first via load_project.

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. 'List' implies a read-only enumeration and it discloses the returned content, but it says nothing about failure modes (invalid/missing .l5x path), permissions, or scale. Adequate but thin for an unannotated 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?

Front-loaded purpose sentence followed by a minimal Args block; very little waste. The Args line is largely redundant with the schema, which keeps it from a 5.

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

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

An output schema exists, so return values need no explanation, and the tool is single-parameter and simple. However, with no annotations and no usage or error context, an agent still lacks guidance on preconditions and failure behavior.

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

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

Schema description coverage is 0% for the single required parameter, so the description must compensate. 'l5x_path: Path to a .l5x file' only restates what the parameter name already implies, adding no format, constraint, or example 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?

States a specific verb and resource ('List all I/O modules in an L5X project') and even names the returned fields (catalog numbers, slot assignments). The resource is unique among the get_*/search_* siblings, so it is distinguishable, though no sibling is explicitly referenced.

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

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

There is no when-to-use guidance, no prerequisites (e.g., whether the project must be loaded first), and no named alternative. Usage is only implied by the tool's name and scope.

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 implies a read/parse operation but says nothing about side effects (does it load state into a session?), what happens on a malformed or unreadable file, or permission/format requirements beyond 'exported from Studio 5000'.

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?

Purpose is front-loaded in one sentence with no filler, and the argument note is compact. The leftover Python 'Args:' docstring formatting is slightly untidy but not wasteful.

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

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

An output schema exists, so return values need not be described, and the input is a single documented path. What is missing is the operational context an agent needs — that this is the prerequisite step for the sibling query tools and any state it establishes.

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% and the schema type is a bare string, so the description must compensate. It does add meaning — the value is a path to a .l5x file exported from Studio 5000 — but gives no detail on path form (absolute/relative) or expected file structure.

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

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

States a specific verb (parse) and resource (L5X file) plus the outcome (project summary), which is enough to tell it apart from the get_* query siblings. It does not explicitly say it differs from them in being the loader/entry point, so it stops short of a 5.

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

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

No when-to-use guidance at all. Crucially, it never states the obvious workflow role — that this must be called before get_tags/get_udts/list_modules — nor any precondition or alternative.

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 behavioral disclosure burden. 'Health check — verify the server is running' communicates that this is a non-mutating status probe. It doesn't detail response contents, but the output schema covers that.

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 lean—five words of substance—and every word adds meaning. The 'Health check' label is front-loaded and the explanatory clause follows directly.

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 parameterless status probe with an output schema, this description is complete. It states the tool's purpose and implied read-only nature; nothing else is required to call 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 tool has zero parameters, so parameter documentation is not needed. The baseline of 4 applies because there is no semantic gap for the description to fill.

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, 'verify,' and a clear resource, 'the server is running.' It also establishes the tool as a health check, which sets it apart from sibling tools like correlate_projects and trace_tag.

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 clearly implies when to call it: any time the agent needs to confirm the server is up. It doesn't contrast against alternatives, but none of the sibling tools are plausible substitutes for a health check, so no exclusion is needed.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful behaviors: the result granularity (every routine/rung/line) and regex support. It is silent on case sensitivity, behavior with an invalid or missing l5x_path, and cost on large projects, so the behavioral picture is only partially filled in.

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

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

Front-loads purpose and return shape, then answers the usage question, then lists args — a sensible order with no filler prose. The args block is somewhat redundant in phrasing but justified given the schema carries no parameter descriptions.

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

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

An output schema exists, so the brief mention of return structure is a bonus rather than a requirement, and the regex capability is disclosed. What remains missing is edge-case behavior — no-match results, invalid paths, case sensitivity — which an agent would want for a search tool over an entire project file.

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 well for `pattern` by explaining it accepts a tag name, AOI name, or regex pattern — information absent from the schema. `l5x_path` is only restated as "Path to a .l5x file," adding essentially nothing beyond the name, which keeps it from a 5.

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

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

States a specific verb (search) and resource (tag, AOI, or pattern) plus the exact scope: across all routines in an L5X project, returning every routine/rung/line that references the match. This clearly separates it from the get_* siblings (get_tag, get_aoi, get_routine), which retrieve a known object rather than locate references to it.

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

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

Gives concrete trigger questions — "Where is this tag used?" and "Which routines reference this AOI?" — that tell the agent exactly when this tool applies. It does not, however, name an alternative or state exclusions (e.g., use get_tag when you already know the tag exists), 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.