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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it says nothing about whether the call is read-only, whether it probes the live system, any latency or side effects, or how the 'why' for hidden tools is determined. It only lists the data categories returned.

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

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

A single compact sentence with the most important content (detected applications, exposed/hidden tools, security policy) front-loaded. Efficient, though it reads as a fragment rather than a structured statement of purpose.

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

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

With no parameters and an output schema present, the description need not explain return values, and it adequately signals the reported categories. However, given sibling overlap with security_policy and software_overview, an agent lacks any signal about how this status view differs from those tools.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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 enumerates the exact content the tool reports: detected applications, which automation tools are exposed or hidden (and why), and the security policy. The purpose is clear, but it is a noun-phrase content list rather than a verb+resource statement, and it does not distinguish itself from overlapping siblings like software_overview or security_policy.

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 call this tool, no conditions or prerequisites, and no mention of the alternative siblings (software_overview, security_policy) that cover similar ground. The agent is left to infer usage entirely.

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 says it 'Returns' a script, yet a parameter is named 'output_file' and there is no indication whether the tool writes a file to disk, mutates anything, or merely returns text with the path substituted in. Permissions and side effects are undisclosed.

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

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

A single efficient sentence front-loads the purpose, followed by the template branch details. The bracketed domain tag adds context without bloat, though the information is densely packed.

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

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

An output schema exists, so return format need not be explained, and the template options are covered. However the behavioral gap around whether output_file triggers file writing leaves the agent under-informed for a no-annotation 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 well: it maps 'export_bom' to (project_path, output_file .csv) and 'pcb_stats' to (output_file .txt), revealing the valid template values, which parameters apply to each, and expected file extensions. It still leaves the exact string values and the output_file file-vs-name semantics unstated.

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: 'Return ready-made DelphiScript' templates, and enumerates the two available templates ('export_bom', 'pcb_stats'). The bracketed domain tag clarifies it is the Altium Designer tool, distinguishing it from the analogous feko_lua_template sibling.

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 presents the two template choices and their parameters, implying when each is used, but gives no explicit when-to-use/when-not guidance and never names a sibling. Usage is inferable from the template list 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?

With no annotations, the description carries the full burden and does well: it discloses the selection heuristic (task-named app if installed, else first installed substitute), that ranking is 'usual first choice', that installation status is included, and that the tool is advisory only. It omits any mention of read-only/auth characteristics, but the content disclosure is unusually 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?

Front-loaded with the core purpose and usage pattern, but the ~27-item parenthetical domain list is dense and occupies most of the text. It is informative rather than filler, yet it blurs the line between conciseness and completeness.

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 unnecessary, and the description covers invocation modes, advisory semantics, and output shape. For a 2-param read tool this is close to complete; only the absence of sibling routing leaves a minor gap.

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 both parameters are bare strings with empty defaults, so the description must compensate, and it does: it explains that area takes an area id and task takes a description used to match areas. It does not map concrete area id values, but the enumerated domains supply that context.

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+resource ('head-to-head comparison of the applications that can do the same kind of task') and enumerates the task domains it covers, so an agent knows exactly what it returns. It does not, however, distinguish itself from the sibling recommend_application, which appears to serve a related advisory function.

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

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

Explicitly gives three invocation modes (no args = list areas, area=<id> = one area, task=<description> = match areas) and clarifies the advisory nature ('Any installed candidate may be used; tell the user which trade-offs apply'). It stops short of stating when to prefer this over recommend_application or list_software.

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 lists the output sections, but with an output schema already present that is largely redundant, and it says nothing about idempotence, permissions, failure modes, or what happens when the entry is not found.

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 compact sentence that front-loads the payload contents with no filler. It is efficient, though the compression contributes to the ambiguity about what a catalog entry is.

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?

Return values are covered by the output schema, so the section list adds little, while the two required parameters and their relationship remain unexplained. For a lookup tool with zero schema documentation, more identifying detail was needed.

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 all three parameters, so the description must compensate. It only implicitly suggests that an entry is identified by name/software; it never explains the required 'software' key, the 'name' key, or what 'as_markdown' toggles, leaving a required parameter pair undocumented.

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 the resource ('one catalog entry') and the kind of content returned ('what it does, usage/syntax, parameters, example, docs link'), but the verb 'describe' is generic and it never clarifies whether an entry is a software package or a tool. Siblings list_tools, search_tools, and software_overview make that distinction important, and nothing here resolves 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?

There is no when-to-use guidance at all. An agent cannot tell from this text whether to call describe_tool, list_tools, search_tools, or software_overview, nor what prerequisite lookup produces the 'software'/'name' pair it needs.

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 does disclose that both directions of transformation exist and that the input/output formats are compressed payload vs XML. It omits error behavior on malformed payloads, size limits, and whether the returned XML is the raw editable source, leaving moderate gaps 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?

Two compact sentences with the core transform front-loaded after the domain tag. Every clause is relevant, though the bracketed diagram-type list is inherited boilerplate that doesn't help an agent invoke this specific codec.

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

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

With an output schema present, return values need no explanation, and the description covers both operational modes of this two-parameter tool. The only shortfall is the unexplained `text` payload semantics per mode, which is a minor gap given the output schema carries the result shape.

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 schema offers no parameter detail. The description compensates for `mode` by explaining decode and encode values (and matching the default), but says nothing about what `text` should contain in each mode (compressed payload vs raw XML), leaving the most important parameter undocumented.

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

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

The description names a specific operation pair (decode a compressed <diagram> payload to XML / encode XML to draw.io format), which is concrete and separable from siblings like drawio_create_diagram and drawio_read. The leading bracketed domain tag ('draw.io: diagrams (flowcharts, ...)') is category boilerplate rather than tool purpose, slightly diluting focus.

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 indicates the two modes and what each does, which implies when you'd pick decode vs encode, but gives no explicit when-to-use guidance relative to drawio_read or drawio_create_diagram. An agent must infer from the mode semantics alone that this is a low-level transform, not a diagram authoring/reading 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 full disclosure burden, and it does add real behavior: layout is automatic (layered, TB/LR) unless x/y are supplied, and export_format triggers an additional render. It does not state whether files are overwritten, where output lands, or what output_file does, so mutation/file-system side effects remain undisclosed.

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 the domain bracket, then the core action, then shape vocabulary, then layout/export behavior. The long shape list is dense but earns its place as the only source of that enum information. Minor redundancy in listing both 'rectangle' and 'rounded' style families, but generally tight.

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?

Because an output schema exists, return-value explanation is not required, and the description covers inputs, shape vocabulary, layout, and export adequately. It omits how output_file interacts with the sibling set_output_folder and whether an export produces a separate file, leaving file-handling behavior under-specified for a creation 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?

Schema description coverage is 0%, so the description has to compensate, and it largely does: it spells out the node object keys {id,label,shape?,style?,x?,y?,width?,height?}, the edge keys {source,target,label?,style?}, the accepted shape vocabulary, direction TB|LR, and export_format png|svg|pdf. Only title and output_file are left unexplained, hence not 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 ('Build a .drawio diagram') plus the ingredients (nodes/edges) and output formats, so the resource and action are unambiguous. The bracket header also frames the draw.io domain. However, it never distinguishes itself from the sibling drawio_flowchart or drawio_codec, so an agent must infer which diagram builder to pick.

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 explicit when-to-use guidance, no exclusions, and no reference to any sibling tool. The description implies usage only by describing the inputs it accepts (nodes/edges), leaving the choice between drawio_create_diagram and drawio_flowchart to inference.

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 does disclose a real behavior beyond the schema: the '?' suffix rule that turns a step into a decision diamond, plus the note that output is an editable file with PNG/SVG/PDF export. It omits anything about file overwrite behavior, where files are written, or auth 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?

A tight two-clause sentence: bracketed capability summary first, then the tool-specific behavior. No filler 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?

For a 5-parameter tool with zero schema descriptions and no annotations, the description answers far less than an agent needs. An output schema exists so return values need not be explained, but four of five parameters and all usage routing remain undocumented.

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% across 5 parameters, so the description must compensate and largely doesn't. It explains the 'steps' semantics (labels, '?' rule) and hints at export format (PNG/SVG/PDF), but 'title', 'direction', and 'output_file' get no meaning at all.

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 ('Quick linear flowchart from a list of step labels') and adds a concrete construction rule (labels ending with '?' become decision diamonds), so an agent knows exactly what artifact is produced. It does not, however, differentiate itself from the sibling drawio_create_diagram, which appears to be the generic 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 says what the tool builds but never says when to pick it over drawio_create_diagram or drawio_codec, nor what preconditions apply. No exclusions, no alternative routing, no 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 full burden, and it does disclose what is extracted and that the XML is decoded. However, 'Read' only implicitly signals a non-mutating operation, and it says nothing about error behavior for malformed/non-drawio files or whether PNG/SVG/PDF inputs are rejected.

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

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

A short domain tag followed by one front-loaded sentence; the verb and resource come before the return-value enumeration. The bracket tag is slightly verbose, but nothing is wasted.

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

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

For a single-parameter read tool with an output schema and a sibling set_output_folder, this is nearly complete: purpose and returned content are covered. The only real gap is path resolution context, plus the bracket tag's 'PNG/SVG/PDF' phrasing, which slightly muddies whether those formats are valid inputs to a read.

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 lone 'path' parameter has 0% schema description coverage, so the description must compensate. It partially does by naming the accepted file types (.drawio/.xml), but it adds no detail on whether the path is absolute, relative, or resolved under the configured output folder.

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 ('Read') and resource ('.drawio/.xml file') and even enumerates what it extracts (pages, vertex/edge counts, labels, decoded mxGraphModel XML). It is clearly distinguishable from drawio_create_diagram and drawio_flowchart, though it never explicitly contrasts itself with drawio_codec, which could plausibly overlap on decoding.

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, and no named alternative. The agent must infer from the verb that this is the inspection path rather than the creation path, and nothing says what to do instead when a file is a PNG/SVG/PDF.

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 does well: it discloses the grouping keys, that parts without a package (frames, supply symbols) are omitted, and that a CSV can optionally be written with relative paths resolving to the current output folder. It omits error/edge conditions but transparently covers the meaningful behavior and side 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 core purpose is front-loaded and the sentences are dense with useful detail. The bracketed '[Autodesk EAGLE ...]' preamble is somewhat verbose tool-family context, but it is separated from the operational description and does not obscure the main statement.

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 re-explained, and the description still covers grouping, exclusions, and file-writing behavior. For a 2-parameter extraction tool with a file side effect and no annotations, this is complete enough to call 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?

Schema description coverage is 0%, so the description must compensate. It conveys that design_file is an EAGLE XML schematic/board (implying format and that no EAGLE install is required) and that output_csv is optional with relative-path resolution semantics, adding meaning 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 states a precise verb+resource: producing a 'Bill of materials from an EAGLE schematic or board (XML, no EAGLE needed)'. It further specifies how the BOM is grouped (value, package, manufacturer, MPN) and what is excluded, so an agent can distinguish it from sibling eagle_netlist or eagle_read_design without opening the 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?

It implies usage via '(XML, no EAGLE needed)' and the optional CSV note, and clarifies the tool works on files directly. However, it never explicitly says when to choose this over eagle_read_design or eagle_netlist, or any prerequisites/exclusions, so the routing guidance is only implied.

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

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

With no annotations, the description carries the full burden. It usefully discloses output format ('XML only') and a side effect (optionally writes a tab-separated text file), which is real behavioral context. It omits permission requirements, error behavior, and any rate limits, leaving notable 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 core sentence is dense and front-loads the netlist definition well. However, the bracketed prefix lists tangential capabilities (CAM, BOM, ULP, scripts) that don't serve this specific tool and add clutter without aiding invocation.

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 needn't be explained, and the description covers the output format and file-writing option. But with two undocumented parameters and no annotations, the description does not fully cover input semantics or usage context, leaving it 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?

Schema description coverage is 0%, so the description must compensate. It hints that the design input is XML and that output_file produces a tab-separated text file, mapping loosely to the two parameters, but never references parameter names or clarifies required vs optional/format expectations. Partial compensation only.

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 resource (netlist) with its exact source and granularity: 'part.pin per net' from a schematic or 'element.pad per signal' from a board, XML only. This clearly distinguishes it from siblings like eagle_bom and eagle_read_design. An agent can tell precisely what this tool produces.

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 (extracting a netlist, optionally to a text file) but never states when to choose this over eagle_bom or eagle_read_design, nor any prerequisites. Usage is inferable but not guided, so this lands at the implied-usage baseline.

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 full behavioral burden. 'Read ... without EAGLE' establishes a safe read operation and independence from the application, but it says nothing about error behavior on malformed files, permission requirements, or the effect of max_items. The content enumeration is informative but overlaps with what the output schema already conveys.

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 main sentence is dense yet front-loaded with the verb and well-organized by document type. However, the bracketed preamble describes the whole EAGLE product suite rather than this tool, adding words that do not help the agent select or invoke it.

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 details are not needed, and the description adequately signals the read-only nature and the domain covered. It still leaves gaps on the max_items parameter and on when to prefer this tool over the sibling eagle_bom/eagle_netlist readers.

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% and neither parameter is explained. design_file is inferrable from its name, but max_items (default 500) is never mentioned in the description, so an agent cannot tell what it bounds—item counts, nesting depth, or pagination—leaving a real comprehension 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 core sentence gives a clear verb+resource ('Read an EAGLE XML design') and enumerates the three document kinds it handles (schematic, board, library). It is reasonably distinguishable from siblings like eagle_bom/eagle_netlist, though the bracket preamble lists BOM/netlist/CAM as EAGLE capabilities, which slightly blurs what this specific tool returns.

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: 'without EAGLE' hints that this is for parsing design XML when the application is unavailable, and the content list implies when to pick schematic vs board vs library. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as eagle_bom or eagle_netlist.

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 behavioral burden. It says nothing about whether the returned scripts are written to disk (overwriting model/output paths?), whether a Feko installation is required, or side effects of running them. Only the template content is described.

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 bracketed product context is front-loaded and the template list is compact, but the single run-on sentence crams domain jargon, four template names, and their outputs together, making it harder to scan than a short bulleted form would be.

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

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

An output schema exists so return values need not be explained, but with zero annotation coverage and 0% schema coverage across four parameters, the description leaves the tool's operating behavior (file writing, toolchain prerequisites) and three parameters unaddressed.

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% and the schema has no enums, so the description's enumeration of kind values ('dipole', 'export_source_data', 'export_farfield', 'rcs_sweep') is genuinely valuable for the required parameter. However, model, output, and frequency_hz are undocumented in both schema and 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?

The description names a concrete resource (ready-made Lua scripts) and enumerates four specific template kinds with their purpose (dipole CADFEKO build+solve, impedance CSV export, farfield export, monostatic RCS sweep). It is not differentiated from the sibling altium_script_template, but the Feko-specific template names make the resource scope unmistakable.

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

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

It lists which templates exist but gives no guidance on when to reach for this tool versus feko_parse_out, altium_script_template, or the other script/output tools. There are no preconditions, exclusions, or alternative routing statements.

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 useful behavioral context: parsing requires no Feko installation, and it names the categories of data extracted. It does not explicitly state that the operation is read-only with no side effects, nor how malformed files are handled.

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 definition is front-loaded with domain context followed by a compact list of parsed contents. Every phrase contributes, though the bracketed Altair Feko domain metadata is somewhat heavy relative to the core parse instruction.

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 in the description, and the description still helpfully enumerates what will be extracted. The remaining gap is the undocumented out_file parameter and the absence of explicit usage exclusions.

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 out_file. The description partially compensates by indicating the input is a Feko .out report, but it adds no path format, file-location, or file-validity details beyond that.

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 plus resource: 'Parse a Feko .out report'. It further enumerates the extracted artifacts (solution frequencies, per-source impedance/current/power, warnings/errors), making the tool's scope unmistakable and distinguishable from unrelated siblings like drawio_read or eagle_read_design.

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 strongly implied: use this when you have a Feko .out report to parse. The parenthetical '(no Feko needed)' clarifies a key dependency condition. However, it provides no explicit when-to-use vs. alternatives guidance or exclusions, and no sibling tool is named.

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 does disclose the return content (categories with tool counts) and implies a read-only lookup, but says nothing about ordering, error behavior for unknown applications, or whether it needs the tool set to be installed first. For a low-risk read this is 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 front-loaded sentence that states the action, resource, scope, and return enrichment, followed by two inline examples. No filler, nothing deferred.

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 re-explained, and the description still adds the useful 'with tool counts' detail plus parameter examples. The residual gap is the lack of validation/format guidance for the software parameter.

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 'software' parameter, so the description must compensate. It partially does so by giving concrete example values ('matlab', 'vivado'), which conveys the expected identifier style, but does not state case sensitivity, accepted names, or whether arbitrary application strings work.

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 gives a specific verb (List) and resource (catalog categories), and adds scope details: it is scoped to one application and returns categories annotated with tool counts. It does not explicitly distinguish itself from list_software or software_overview, but the purpose is unambiguous on its own.

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 by the example application names ('matlab', 'vivado'); there is no 'use this when...' framing, no mention of prerequisites, and no routing to alternatives such as software_overview or list_software. An agent can infer the call, but nothing steers it between 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?

With no annotations, the description carries the full burden, and it does disclose the returned fields (catalog size, whether the executable was found locally), which is useful behavioral context for a listing operation. It does not state that the call is read-only, side-effect free, or how the local-executable check is performed, leaving gaps in an annotation-free definition.

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

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

A single front-loaded sentence that states the action and the two result facets with no filler. Nothing could be cut without losing information.

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

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

For a zero-parameter listing tool with an output schema present, the description explains enough of the return content that return values need not be detailed further. Only the absence of any usage routing against software_overview keeps it from being 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?

The tool takes zero parameters, so the baseline is 4 — there is nothing for the description to clarify beyond what the empty schema already conveys.

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

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

The description names a specific verb (List) and resource (supported applications) and even previews the payload — catalog size and local executable presence. It is clearly distinguishable from noisy siblings like adapter_status or list_categories, though it does not explicitly differentiate itself from the nearby software_overview 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?

There is no when-to-use or when-not-to-use guidance and no named alternative, despite a sibling (software_overview) that plausibly overlaps. An agent must infer from the description alone that this is the enumeration tool rather than an overview.

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. It discloses the return shape ('compact rows') and a non-obvious filtering behavior ('category substring'), but omits pagination behavior, permissions, and read-only nature.

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

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

Two sentences with no filler. The purpose and main filtering behavior are front-loaded, followed by a concise note on return format and the next tool to use.

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 output schema covers return values, and the description is adequate for basic listing. However, with no annotations and 0% schema description coverage, gaps around pagination and the required software parameter leave the agent without enough context to use the tool confidently in all cases.

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 for all five parameters. It partially covers category substring and kind, and implies software via 'for an application,' but leaves the required software parameter unnamed and completely omits limit and offset.

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 gives a specific verb and resource: 'List catalog entries for an application,' with optional filters. It distinguishes itself from describe_tool by redirecting usage there, but does not differentiate from sibling tools like search_tools or list_software.

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 only says 'Use describe_tool for usage and examples,' which is downstream guidance rather than when-to-use-this-tool guidance. There is no explicit comparison to alternatives like search_tools or list_software, and no when-not-to-use 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?

With no annotations provided, the description carries the full behavioral burden. It discloses what the parser returns (errors, warnings, node voltages, total power), which is genuinely useful, but says nothing about failure modes, file-format requirements, permission needs, or output structure beyond 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?

A single front-loaded sentence with the domain tag prefix and the core action stated immediately. Compact and free of filler, though the bracketed vendor tag adds minor clutter.

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 single required parameter is conceptually covered. What remains missing is usage routing against sibling parsers and any note on malformed or missing files.

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 single parameter 'out_file' has only the title 'Out File'. The description does add meaning by specifying it is an 'existing PSpice .out file', clarifying format and existence expectations, but no path syntax or relative/absolute guidance is given.

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 (PSpice .out file) and enumerates what is extracted: errors, warnings, node voltages, total power. It is clearly distinguishable from other tools, though it does not explicitly name a sibling like feko_parse_out as an alternative.

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 word 'existing' hints that a file must already be present, but there is no explicit when-to-use guidance, no prerequisites, and no alternatives named among the many sibling tools. Usage must be inferred.

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 behavioral burden. It usefully signals a read-only inspection that does not require the Proteus application, which is meaningful context. However, it says nothing about permissions, error handling, or constraints, and a read-only nature is only implied by 'Inspect.'

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

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

A single sentence, front-loaded with the domain label and the verb+object. The bracketed preamble is slightly verbose but earns its place by establishing the Proteus context, and there is no wasted text.

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. For a one-parameter read-only inspection tool, the description covers purpose and output content adequately; only usage guidance is thin.

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 single parameter has 0% schema description coverage, so the description must compensate, and it does by naming the expected file format ('.pdsprj container'). That directly clarifies what 'project_file' should point to, though it adds no detail about the parameter's type or path conventions.

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 ('Inspect') and resource ('a .pdsprj container'), and enumerates what it extracts: embedded files, firmware references, MCU hints. The bracketed prefix identifies the Proteus domain. No sibling differentiation is needed since the surrounding sibling tools (EAGLE, Altium, drawio, time utilities) operate on entirely different artifacts, but the definition never explicitly distinguishes itself 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?

The phrase 'without opening Proteus' implies a use case (inspecting a project when the application is unavailable or undesirable), but there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. Usage is inferable but not 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?

With no annotations provided, the description carries the full behavioral burden and does so well: it states that the result is a ranked list with matched terms, installation status, tool prefix, and head-to-head comparisons including strengths, choice criteria, and limits. It also clarifies that the result is a suggestion rather than a binding rule.

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 front-loaded with the core purpose, then adds examples, usage timing, return behavior, and fallback guidance. It is somewhat long, but the details are relevant and structured rather than redundant.

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

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

Although an output schema exists, the description still provides enough context about the returned recommendation, ranking, installation status, and comparison details. It also covers when to call the tool and what to do when its suggestion cannot be followed, making it complete for an agent.

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 for the single required 'task' parameter is 0%, so the description must compensate. It does this by giving concrete examples of task domains and their matched applications, implying that the parameter is a free-text engineering task description, though it could more explicitly define the expected 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 uses a specific verb phrase, 'Suggest which application (and tool family) fits an engineering task best,' and immediately grounds it with domain-to-application examples such as antennas -> HFSS and PCB -> Altium. This makes the tool's function distinct without needing to inspect schemas or sibling 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 explicitly says 'Call this before choosing tools for a task,' which gives a clear usage point. It also explains a fallback when the suggested application is unavailable or the user prefers another, though it does not name a sibling alternative such as compare_applications.

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. It does disclose the ranking behavior (by name/category/description matches), which is useful, but says nothing about scoping semantics, result limits, or how the 'applications' filter interacts with results.

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

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

A single front-loaded sentence that leads with the verb and resource and adds the ranking detail. Efficient, with no filler, though it is arguably under-specified rather than trimmed.

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

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

An output schema exists, so return values need not be explained, but with 5 parameters, 0% schema coverage, and no annotations, the description leaves critical inputs (kind, limit, category) and scope behavior undocumented. Inadequate for this parameter count.

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 hints at keyword(s) (query) and applications (software) and ranking fields, but leaves kind, limit, and category entirely undocumented in both schema and description, so the meaning of 3 of 5 params is unaddressed.

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 (catalogs), and notes scope across all applications or one, ranked by name/category/description. It is clearly a keyword search, distinguishing it from list_tools and describe_tool, though it does not name siblings 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?

The phrase 'across all applications or one' implies a scoping choice, but there is no explicit when-to-use guidance or named alternative (e.g. use list_tools to enumerate vs search_tools to find by keyword). Usage is only implied.

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

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

No annotations are provided, so the description carries the burden. It discloses the content domains (policy mode, disabled tools, change procedure, output folder rules), which is useful, but says nothing about whether the call is read-only, side effects, or permissions. Its query-only, zero-parameter nature limits the risk, keeping this at a middling score rather than low.

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

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

A single dense sentence with a parenthetical enumerating the covered topics; front-loaded and free of filler. Slightly long but every clause 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?

With an output schema present, return values need no explanation, and the description adequately covers the two subject areas (security policy and output folder rules) for a no-argument informational tool. Only the omission of read-only/side-effect context keeps it from a 5.

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 takes zero parameters and schema coverage is 100%, so there is nothing for the description to add or explain. Baseline 4 applies for a no-argument tool.

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

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

The description names a clear resource (effective network/internet policy and output folder rules) and enumerates the specifics it covers (local-only vs network mode, disabled tools, how to change it). It is distinguishable from most siblings, though the verb is implicit (it reports/describes rather than stating an action).

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 explicit guidance on when to call this versus siblings such as set_output_folder, describe_tool, or list_tools. The content enumeration hints at usage but no conditions, prerequisites, or alternatives are 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?

With no annotations, the description carries the full burden and does so richly: persistence scope (applies to the server process and all chats of this client until changed or restart), precondition (folder must already exist on a local disk), refusal rules (drive roots, home, hidden/system/program/app-data/network), env-var override (MCP_ADAPTER_OUTPUT_ROOTS), and subfolder layout 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 primary effect is front-loaded in sentence one, and the remaining sentences cover constraints, precedence, and persistence without filler. It is dense but slightly long and switches between operational and policy detail, which mildly dilutes scannability.

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; what matters — preconditions, refusal cases, scope of the setting, and revert behavior — is all present. For a two-parameter, non-destructive configuration tool this is 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?

Schema description coverage is 0%, so the description must compensate, and it does for both parameters: it defines what 'folder' means (the user-granted task folder, must pre-exist, empty string restores default) and what 'per_application_subfolders' does (each application writes into its own subfolder unless false).

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 (write generated scripts/results into a chosen folder) and explicitly contrasts it with the alternative behavior (the adapter's default outputs folder). No sibling tool overlaps this, and an agent can tell immediately it is a configuration/setter tool rather than an execution 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?

Gives explicit ordering guidance ("Call it first in a task that has a folder"), the condition for use (a task that has a folder given/granted by the user), and the condition for reverting (an empty folder goes back to the default). Nothing about when or when-not to call is left to inference.

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. It does disclose the richness of the return payload, including install status and entry points, which is real context. However it never states that this is a safe read with no side effects, nor any auth or caching behavior, leaving an agent to assume rather than know.

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 dense sentence front-loads the payoff and uses a colon list to enumerate contents efficiently with no filler. The trade-off is length, but every clause maps to a distinct piece of returned information.

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

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

An output schema exists, so return-value structure need not be restated, and the description still usefully previews content. What is missing is the parameter contract and any when-to-use routing relative to the many sibling tools, which for a lookup tool is a meaningful gap.

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 single required 'software' parameter has 0% schema description coverage and the description adds nothing about it. It doesn't say whether the value is a display name, an ID, a slug, or a path, nor what happens on an unknown value, so the description fails to compensate for the coverage 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 enumerates exactly what the tool returns: best-for guidance, typical tasks, anti-use cases, capability areas, automation entry points, and install status. That is a specific resource scope an agent can distinguish from describe_tool or list_software, though the verb is implicit and it never states it is read-only informational.

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 one concrete routing hint, telling the agent to browse capability areas with list_tools, which is useful. But it never says when to call software_overview versus list_software, describe_tool, or recommend_application, so the choice among siblings is left to inference.

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, but it does disclose one non-obvious behavior: negative values perform subtraction. It says nothing about DST handling, timezone conversion behavior, the default of datetime='now', or whether out-of-range units are normalized.

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 short sentence, front-loaded with the core action, with the negative-value caveat folded in parenthetically. Nothing is wasted or buried.

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 an 8-parameter, unannotated utility tool with no schema descriptions, the definition is too thin. The output schema relieves it of explaining return values, but format, timezone, and datetime-default semantics are essential to calling this correctly and 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% across 8 parameters, so the description must compensate and does not. It never explains format, timezone semantics, or the datetime default ('now'), leaving the agent to infer the meaning of the format and timezone strings from parameter titles alone.

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 (add/subtract) and resources (duration, date/time), making the operation unmistakable. It does not name any sibling such as time_difference or time_now for contrast, but the purpose is clear on its own.

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

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

Use is implied: this is the tool for shifting a datetime by a duration, and the negative-value note hints at reversal. There is no explicit when-to-use or when-not-to-use guidance, and no routing advice against siblings like time_difference or time_convert.

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 behavioral burden. It does add real value by disclosing accepted input forms (ISO 8601, unix timestamps, 'now', 'today'), which is behaviorally meaningful. It says nothing about DST handling, invalid timezone behavior, or how the optional format string affects output, leaving core behavior undisclosed.

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

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

Two short sentences, zero filler, with the core action front-loaded and the input-format detail immediately after. Nothing is redundant or 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 the required datetime parameter is covered. Still, with zero annotations and zero schema coverage, the undefined format parameter, timezone identifier convention, and DST/error behavior leave the definition thinner than a 4-parameter conversion tool warrants.

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% across 4 parameters, so the description must compensate. It documents the datetime parameter's accepted formats well, and 'between timezones' weakly implies from_timezone/to_timezone, but the format parameter is never mentioned and no defaults or timezone identifier syntax (IANA name vs. offset) are given.

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: 'Convert a date/time between timezones.' That is unambiguous about the operation. However, it does not differentiate itself from adjacent siblings such as time_format, time_unix, or time_world_clock, so an agent must still infer which is the right pick for a given request.

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 explicit when-to-use, when-not-to-use, or alternative tool guidance. The description implies a timezone-conversion context but never says how it relates to time_format or time_world_clock, which overlap in domain. The input-format list is parameter information, not 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?

No annotations are provided, so the description carries the full behavioral burden and falls short. It discloses output units (useful), but says nothing about accepted input date formats, how timezone affects the result, DST boundaries, or what happens with a future start or past end.

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

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

A single front-loaded sentence with no filler. It spends part of its length enumerating return units, which is arguably redundant given an output schema exists, but the sentence is efficient overall.

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 output schema covers return values, so that need not be restated, but for a date-parsing tool the critical missing piece is the accepted input format and timezone semantics. With no annotations and 0% schema coverage, the definition is under-specified for correct 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?

Schema description coverage is 0% for 3 parameters, so the description must compensate, and it does not. It never mentions the timezone parameter, the 'end' default of 'now', or the required string format for 'start' and 'end'.

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 operation (elapsed time between two date/times) and enumerates the return units, which cleanly separates it from siblings like time_add and time_now. It does not explicitly name or contrast those siblings, but 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?

No guidance on when to pick this over time_add, time_convert, or time_now, and no mention of prerequisites or handling when only one endpoint is supplied. Usage is only inferable from the name and the phrase 'between two date/times'.

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 behavioral burden. It does not state that this is a side-effect-free transformation, nor does it explain the 'now' default for datetime, timezone handling, or whether the input must be an ISO string – all relevant for a formatting 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?

A single front-loaded sentence; the action and mechanism come first and the strftime example earns its place by showing the expected token syntax. 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?

An output schema exists, so return values need not be explained, but with 0% schema description coverage the accepted input formats for datetime and timezone, and the behavior of the defaults, are unspecified. For a three-parameter tool with no annotations, this leaves material 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?

Schema coverage is 0% across three parameters. The description explains the format parameter via the strftime pattern and example, but says nothing about the datetime input format (default 'now') or the timezone parameter, leaving two of three parameters undefined in both schema and 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?

States a specific verb (format) plus resource (date/time) and the exact mechanism (strftime pattern) with a concrete example. This implicitly distinguishes it from sibling tools like time_convert, time_add, or time_now, but it never names or contrasts with those siblings explicitly.

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

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

There is no statement of when to use this tool versus siblings such as time_convert, time_now, or time_unix. The example shows how to invoke it but gives no context or exclusion criteria for selecting it.

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 behavioral burden. The verb "List" clearly conveys a safe read-only enumeration, but there is no mention of pagination (the limit param implies batching), result size, or browsing behavior, leaving meaningful 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?

A single tight sentence with the core purpose front-loaded and the filter behavior and examples appended. 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?

For a low-complexity list tool with an output schema (so return values need not be described), the definition is mostly adequate, but the undocumented limit parameter is a real hole and no alternative routing is offered among numerous time siblings.

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 successfully explains the filter parameter's semantics (substring matching) with examples, but completely omits the limit parameter, leaving half the parameters undocumented anywhere.

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 IANA timezone names") plus the optional filter capability, so an agent can quickly tell it retrieves timezone identifiers. It does not explicitly differentiate itself from time siblings like time_world_clock or time_convert, leaving that inference to the agent.

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 the usage context via "optionally filtered by substring" with concrete examples ('Asia', 'London'), which hints at lookup/discovery scenarios. However, it never states when to use this versus sibling timezone-related tools, nor any conditions 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?

No annotations are provided, so the description carries the burden; it is a read-only operation with no destructive concerns, which is straightforward. It discloses the return contents (ISO 8601, unix epoch, offset, DST, weekday, ISO week), which adds behavioral context, but this overlaps with the existing output schema and it says nothing about execution behavior beyond output.

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 tight sentences, front-loaded with the core purpose followed by the return detail. Almost every clause earns its place, with only minor redundancy against the output schema.

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 read-only time-lookup tool with an output schema already documenting return fields, the description covers the essential contract: what it returns and how timezones are specified. The only meaningful gap is the format parameter's exact 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%, so the description must compensate. It usefully explains the timezone parameter's accepted forms (IANA name, 'local', 'EST', '+03:30'), but the 'format' parameter is only alluded to via 'an optional strftime-formatted string' without naming it or its syntax, leaving half the parameters thin.

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+resource: retrieving the current date/time in a given timezone. It clearly differs from siblings like time_convert, time_add, and time_difference, which perform transformations rather than reading the present moment. It does not name an explicit sibling, but the intent 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?

Usage is implied (get the current time now) rather than stated. There is no explicit when-to-use versus alternatives guidance, nor mention of when-not to use it against siblings such as time_world_clock or time_format. Adequate but with clear gaps.

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 behavioral burden. It does not explain how seconds vs milliseconds output is selected (no parameter appears to control it), what happens with timezone defaults, whether it is pure/read-only, or any error behavior, leaving real gaps for a conversion 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?

A single front-loaded sentence with no filler; the operation and its output unit lead the description. Nothing wasteful 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?

An output schema exists, so return values need not be spelled out, but the definition still omits the input format, timezone handling, and unit-selection behavior across two undocumented parameters with no annotations. For a conversion tool this is thinner than an agent needs.

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 largely does not. It hints that 'now' is an accepted datetime value, but the timezone parameter is never mentioned and accepted date formats are unspecified, forcing the agent to guess at both inputs.

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 gives a specific verb+resource ('Convert a date/time to unix epoch seconds/milliseconds') and names the output unit, which is concrete. However, it does nothing to separate itself from close siblings like time_convert, time_now, and time_format, and the 'seconds/milliseconds' phrasing leaves the actual output type ambiguous.

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 statement of when to use this tool versus time_convert, time_now, or time_format, all of which plausibly overlap. The parenthetical "(or 'now')" even encroaches on time_now's territory without explaining the distinction, so the agent gets no 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that omitting zones yields ten major zones (explaining the null default), but says nothing about timezone string format, DST handling, or error behavior. One meaningful trait is disclosed, but significant behavioral context is missing.

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

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

A single, front-loaded sentence with zero filler, and the key behavioral default is parenthetical 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?

An output schema exists so return values needn't be described, but for a 3-parameter tool with 0% schema coverage and no annotations, the description omits critical input semantics (datetime and from_timezone formats and defaults). It is not complete enough to invoke confidently without guessing.

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 for all three parameters. It only clarifies zones (defaults to ten major zones); datetime and from_timezone are left entirely unexplained, including expected formats and the relationship between datetime and from_timezone.

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 (Show) and resource (one instant across several timezones), which is clear and distinct from siblings like time_now and time_convert. However, it doesn't explicitly name the sibling alternatives it differs from, leaving differentiation implicit.

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

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

Provides no when-to-use guidance, no conditions that select this tool over time_convert, time_now, or time_list_timezones, and no exclusions. Usage is only loosely implied by 'across several timezones'.

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