device-house

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

The description discloses that it routes and returns a summary, and that failures are indicated by 'failed'. However, it does not mention side effects (e.g., modifies the PCB file), error handling, or limitations. With no annotations, the description carries the full burden but gives minimal behavioral detail.

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

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

The description is a single sentence that is dense and informative. It uses parentheses for additional context. It is front-loaded and efficient, though it may be slightly cryptic due to Japanese phrasing.

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

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

Given the complexity of a routing tool with one ambiguous parameter and no output schema, the description is incomplete. It does not explain prerequisites, output format, or how to interpret the summary. The lack of parameter documentation further undermines completeness.

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

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

The input schema has one required parameter 'prompt' with no description, and schema description coverage is 0%. The description does not explain what the prompt is for, leaving its purpose ambiguous. It fails to add meaning beyond the schema.

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

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

The description clearly states it routes with a 2-layer autorouter and returns a summary of routing rate and via count. It also notes that unrouted is considered failed. This is specific and distinguishes it from sibling tools like get_netlist or parts_add.

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

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

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., need a netlist or board open) or contexts where it is appropriate. Among siblings, no other routing tool exists, so it is unique, but usage context is missing.

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

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

Since no annotations are provided, the description carries the full burden. It discloses that the tool mechanically checks, judges controllable indicators, and honestly reports on real-world tests without exaggeration. This gives a clear behavioral picture, though it omits details like output format or error handling.

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

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

The description is two sentences, front-loading the main purpose (regulatory compliance check) and then adding behavioral detail. Every sentence is meaningful with no redundancy.

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

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

Given one parameter, no output schema, and no annotations, the description is fairly complete. It covers purpose, scope (specific regulations), and behavioral honesty. Lacks details on output structure or error cases, but sufficient for a single-input tool.

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

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

The single parameter 'prompt' is described in the schema as 'evaluate device in words', and the description adds context that it applies to devices designed from words and covers specific compliance areas. Schema coverage is 100%, and the description adds meaningful context beyond the schema.

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

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

The description clearly states the tool checks regulatory compliance (技適/PSE/CE/FCC/RoHS and procurement) for devices designed from words. It specifies which aspects it can judge (design-controllable) and which it honestly flags as requiring real-world tests. This is specific and distinguishes from sibling tools like eval_device.

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 when needing compliance checks for a device description, but does not explicitly state when to use this vs alternatives like eval_device or manufacturing_readiness. No when-not or prerequisite guidance is provided.

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 fully disclose behavior. It mentions the evaluation axes but does not state whether the tool is read-only, requires authentication, or has side effects. The description lacks details on what happens to the device or how results are 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?

The description is a single sentence, efficient and front-loaded with the action. However, for a tool with no annotations and a single parameter, it could include more detail without becoming verbose.

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

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

Given the single parameter, no output schema, and no annotations, the description is minimal. It does not explain the scoring axes in detail, nor the format of the return value. The tool's full behavior must be inferred, which is a gap in completeness.

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

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

Schema coverage is 0%, so the description must compensate. It adds context that the 'prompt' parameter is used for designing a device from words, but it does not specify format, constraints, or examples. The translation adds some meaning but is insufficient for precise invocation.

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

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

The description clearly states the tool's purpose: scoring generation quality of devices from text prompts on 5 specific axes (intent/parts/feasibility/completion/honesty). It distinguishes itself from siblings like 'generate_device' by focusing on evaluation rather than generation.

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 after generating a device, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tools are mentioned, leaving the agent to infer 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?

No annotations are provided, so the description carries the full burden. It mentions that the package includes pre-wired files and that uploading leads to payment, but does not describe what happens on invocation (e.g., file generation, API calls, UI opened). The behavioral context is incomplete; for example, it is unclear whether the tool creates files locally or triggers an external process.

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

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

The description is very short (two sentence fragments in Japanese), which is concise but at the cost of clarity. It front-loads the main purpose, but lacks structure (e.g., no bullet points or separate sections). For a tool with two parameters, more structure would be helpful.

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

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

Given the tool's complexity (involving file generation and upload), the description is incomplete. It does not explain expected outputs, error cases, or how it fits into the broader workflow (e.g., what happens after upload). No output schema exists, so the description should provide more context.

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

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

The input schema has two parameters ('qty' and 'prompt'), but the description provides no explanation of their meaning or usage. With 0% schema description coverage, the description fails to add any value beyond the schema itself. 'prompt' is required but not clarified, leaving the agent guessing.

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 it is an order package overview (Gerber, BOM, CPL, procedure set) and mentions uploading to JLCPCB for ordering. This clearly identifies the tool's purpose as generating a fabrication order package. It distinguishes from siblings like 'get_bom_csv' which are more specific. However, the Japanese wording may be less clear to non-Japanese speakers, and the phrase '盛らない' is 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?

The description gives minimal guidance: '盛らない=実支払いは人間ゲート' (don't overdo = actual payment is human gate) implies that payment requires manual intervention, but does not explain when to use this tool versus alternatives like 'autoroute' or 'eval_device'. No explicit when-to-use or when-not-to-use conditions are provided.

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 must bear the full burden. It discloses the tool returns BoM, enclosure, price, and all-axis score, but does not clarify side effects, persistence, or whether the operation is generative and potentially expensive.

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 a single concise sentence in Japanese that covers input and all key outputs with no extraneous 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?

Given the absence of an output schema and the complexity of a generative design tool, the description mentions essential outputs but lacks detail on the 'all-axis score' and whether this creates a persistent record or is a one-time calculation.

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

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

The input schema covers 100% of the single parameter with a descriptive example. The description adds no further meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool designs a device from a textual description (words/purpose) and returns BoM, enclosure, price, and all-axis score. This distinguishes it from sibling tools like eval_device or get_bom_csv.

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 when generating a device design from words, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria.

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

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

The description discloses that LCSC numbers are unverified and left blank, which is a useful behavioral note. However, since no annotations exist, the description could better address safety or idempotency, though the tool appears read-only.

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 a single, concise sentence covering output format and a notable behavior. However, the Japanese language may reduce clarity for English-oriented agents, and it omits parameter details.

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

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

The description gives basic output format but fails to document the input parameter. With no output schema, more detail on fields or constraints would be helpful. The tool has low complexity, so the description is incomplete.

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

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

The input schema has a single required parameter 'prompt' with no description and 0% schema coverage. The description does not explain the parameter's purpose, leaving the agent without critical usage information.

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

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

The description clearly states the tool returns a BOM CSV in JLCPCB format with specific columns (Comment,Designator,Footprint,LCSC), distinguishing it from sibling netlist tools. However, no explicit differentiation from alternatives is provided.

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

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

No guidance is given on when to use this tool vs siblings like get_netlist or get_kicad_netlist. The description lacks any context for appropriate usage.

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 fails to disclose behavioral traits such as side effects, destructive actions, or security implications. It only states the tool returns a template.

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

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

The description is extremely short but at the expense of completeness. It is not appropriately sized for the complexity of the tool, omitting essential details.

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

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

Given the one required parameter and no output schema or annotations, the description is severely incomplete. It fails to explain input semantics, output format, or any behavioral implications.

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 parameter 'prompt' is completely undocumented. The description adds no meaning to the parameter, leaving the agent uncertain about input format or constraints.

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

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

The description clearly states the tool returns an Arduino firmware template (.ino) for a device designed from words. It uses a specific verb and resource, distinguishing it from sibling generation 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?

No guidance on when to use this tool versus alternatives or any prerequisites. The description lacks context for optimal usage.

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 states the output is a netlist file with certain properties, but does not disclose whether the tool is read-only, if it modifies any state, or any prerequisites. The agent is left to infer behavior.

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

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

The description is very concise, consisting of a single sentence. However, it lacks structure, such as separating purpose from usage or parameter details. The conciseness sacrifices clarity for brevity.

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

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

Given the extremely lean schema (one undocumented parameter) and no output schema or annotations, the description should compensate with more details about input requirements, output format, and side effects. It does not, leaving significant 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%, and the description does not explain the single parameter 'prompt'. With no documentation of what 'prompt' should contain (e.g., board design, net name), the agent cannot effectively invoke the 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 clearly states that the tool outputs a KiCad netlist (.net) and implies it is for production-ready designs with verified footprint assignment, wiring, and DRC. This distinguishes it from the sibling 'get_netlist' tool. However, the phrasing is somewhat vague and could be more specific.

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

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

No explicit guidance on when to use this tool versus alternatives like 'get_netlist' or 'autoroute'. The context implies it is for KiCad production netlists, but there are no exclusions or explicit context cues.

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 provided. The description does not disclose side effects, auth requirements, error behavior, or performance characteristics. For a tool that likely reads data, this is minimal.

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

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

Extremely concise—only one sentence. But conciseness sacrifices completeness; it could be slightly longer to add value.

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

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

Given no output schema, no annotations, and one unexplained parameter, the description leaves the agent guessing about input and output. Incomplete for effective use.

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

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

The single parameter 'prompt' has no schema description (0% coverage) and the tool description does not explain its purpose or expected format. The agent has no clue what to provide.

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

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

The description states it returns a wiring netlist specifically for autoroute input, which is clear. However, it does not differentiate from sibling 'get_kicad_netlist', which might serve a similar purpose.

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

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

No guidance on when to use this tool vs alternatives like 'autoroute' or 'get_kicad_netlist'. The description only states its function without 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?

No annotations are provided, so the description carries full burden. It discloses the output format and color meanings, but fails to explain what the 'prompt' parameter expects, how it affects behavior, or what happens if the PCB is not wired. No side effects or auth needs are mentioned.

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 a single sentence that is concise and front-loaded with key information (what it returns and layer colors). However, it could be slightly more structured by separating parameter details.

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

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

Given the tool has one required parameter and no output schema, the description lacks completeness by not explaining the parameter. The agent needs to know what 'prompt' does to generate the SVG, making this insufficient.

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%, yet the description adds no explanation for the sole required parameter 'prompt'. The parameter's purpose, format, or constraints are entirely undocumented, leaving the agent unable to correctly invoke the 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 clearly states it returns a 2-layer SVG preview of a wired PCB with specific color coding for layers (red top, blue bottom), distinguishing it from other PCB-related tools like get_placement or get_bom_csv.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The sibling tools are diverse but no comparative context is given.

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

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

No annotations are present, so the description must fully disclose behavioral traits. It merely states that the tool returns a CPL CSV but does not mention any side effects, authentication needs, rate limits, or output properties. For a data retrieval tool, this is minimal.

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 a single sentence with no redundancy. Every word is necessary. However, conciseness is achieved at the expense of 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?

Despite the tool's simplicity (one parameter, no output schema), the description fails to provide essential context: what the parameter expects, the format of the returned CSV, or any constraints. The agent would struggle to invoke it correctly without external knowledge.

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

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

The input schema has one required parameter 'prompt' with no description, and the schema description coverage is 0%. The tool description does not explain what 'prompt' means or how to use it. This leaves the agent completely without guidance on the parameter's purpose.

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

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

The description clearly indicates that the tool returns JLCPCB component placement data in CPL CSV format. The verb '返す' (return) and resource '部品配置' (component placement) are specific. However, it does not differentiate from sibling tools like get_bom_csv or get_netlist; the distinction is implied by the resource type.

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

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

No guidance is provided on when to use this tool compared to alternatives. There is no mention of prerequisites, typical use cases, or scenarios where another tool would be more appropriate.

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 fully disclose behavioral traits. It only indicates that the tool lists device types, without mentioning whether it is read-only, idempotent, or any side effects. It does not describe the output format or behavior beyond the listing.

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 a single sentence that conveys the purpose concisely. It is front-loaded and to the point. However, it is only available in Japanese, which may reduce clarity for non-Japanese users.

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

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

Given the absence of parameters and output schema, the description minimally explains what is returned (list of device types). It does not elaborate on the composition of the list or its use cases. For a simple list tool, it is adequate but lacks completeness for an agent unfamiliar with device.house.

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

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

The tool has no parameters, so schema coverage is trivially 100%. The description does not need to add parameter information, but it also does not add any additional context about the parameters (which is not needed). A baseline score of 4 is appropriate as it does not detract.

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

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

The description clearly states it lists device types that can be designed from words in device.house. It specifies the resource (device types) and implies the verb 'list'. However, the description is in Japanese and may be slightly ambiguous about the exact scope.

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

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

No guidance on when to use this tool versus alternatives like list_catalog or other sibling tools. The description does not mention prerequisites or context for use.

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 provided, so description carries full burden. It only states the output fields, not whether the tool is read-only, has side effects, or requires authentication. Minimal behavioral context.

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

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

Description is a single sentence, no fluff, and front-loaded. Could be slightly more direct (e.g., 'List devices in catalog' instead of 'selectable device catalog').

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

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

Given no output schema and no annotations, description is adequate but lacks return format details, default behavior when no filter, and any response constraints. Gaps remain.

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

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

Schema coverage is 100% with a description for the 'room' parameter. The tool description adds context about the catalog content but not about the parameter itself. Baseline 3 per guidelines.

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

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

Description clearly states it is a device catalog for rooms (like bim.house), listing price, dimensions, recommended room, and deep link. This distinguishes it from sibling tools like parts_list (parts) and parts_search (search).

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

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

No explicit when-to-use or alternatives mentioned, but the purpose is clear enough to infer usage. It does not provide exclusions or conditions for use.

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

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

No annotations exist, so the description must fully disclose behavior. It mentions 'honest entity evaluation' and lists evaluation criteria, but does not clarify whether the tool modifies any state, requires specific permissions, or what the output format is. This leaves significant ambiguity for an AI agent.

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

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

The description is brief (one sentence) but the structure could be improved. It front-loads the key concept but ends with a question that may confuse agents. It is concise but sacrifices clarity needed for automated decision-making.

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

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

Given the tool's complexity (manufacturing readiness evaluation) and the absence of an output schema, parameter descriptions, and annotations, the description is severely incomplete. It provides only a high-level idea without sufficient detail for an agent to invoke the tool correctly.

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

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

The input schema has a single required 'prompt' parameter with no description, and the tool description does not explain what the prompt should contain. With 0% schema description coverage, the description fails to compensate, leaving the agent without guidance on how to use the parameter.

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 tool evaluates manufacturing readiness, including aspects like footprint, LCSC, DRC, fits, and wiring, and asks if it can be made into a working board when ordered. This clearly defines the tool's purpose and distinguishes it from sibling tools that focus on individual tasks like autorouting or device evaluation.

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

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

No explicit guidance on when to use this tool versus alternatives is provided. The description implies it is used for a comprehensive readiness check, but does not specify prerequisites, constraints, or scenarios where other tools might be more appropriate.

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

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

With no annotations, the description must convey behavioral traits. It indicates persistence and automatic slug generation from part number, but fails to disclose critical behaviors like overwrite policy, error handling, validation, or 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 description is very short and front-loaded, but for a tool with 9 parameters, it is too brief. Conciseness is good, but under-specification reduces utility; every sentence should earn its place, but here it omits necessary details.

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

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

Given the tool's complexity (9 parameters, no output schema, no annotations), the description is woefully incomplete. It does not explain return values, error conditions, or the overall behavior beyond persistence and ID generation.

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?

Only 11% of parameters are documented in the schema, and the description only adds meaning for the 'id' parameter (optional, slug generated). The other 8 parameters (cat, src, desc, unit, keywords, footprint, interface) receive no explanation, leaving a significant 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 clearly states that the tool adds a part and persists it in the user catalog, and mentions that the id can be omitted. It is specific about the action and resource, but does not explicitly distinguish it from sibling tools like parts_update or parts_import, though the name implies addition.

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

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

No guidance is provided on when to use this tool versus alternatives such as parts_update or parts_remove. There is no mention of prerequisites, when not to use, or context for invocation beyond the implied addition action.

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 provided, so the description must disclose behavior. It only states the operation is a retrieval, without discussing idempotency, error conditions, or whether it returns the full part object.

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

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

Single sentence with no wasted words. Efficient, though slightly too brief for completeness. Structure is straightforward.

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 one-parameter retrieval, the description adequately explains the purpose and parameter. However, it lacks information about the return value, which is not covered by an output schema.

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

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

The schema has 0% description coverage, and the description only mentions 'id' as the key. It adds minimal meaning beyond the schema, not specifying format or constraints.

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 'id でパーツ1件取得' clearly indicates retrieving a single part by ID, distinguishing it from siblings like 'parts_list' (list) or 'parts_search' (search). The verb+resource is specific and unambiguous.

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

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

No guidance on when to use this tool versus alternatives such as 'parts_search' or 'parts_list'. The description implies usage when an ID is known, but lacks explicit context 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 bears full responsibility for behavioral traits. It only states that the tool lists parts and can filter them, but does not disclose that it is read-only, whether pagination exists, or any side effects. This lack of transparency limits the agent's ability to use it safely.

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 a single short sentence, which is front-loaded and efficient. It contains no wasted words, but the brevity sacrifices some informational depth that might be valuable.

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 output schema and simple parameters, the description is minimally adequate. However, it does not specify the return format, pagination, or ordering, and given the presence of sibling tools like parts_search, more context on when to use this list vs search would improve completeness.

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%, meaning no property descriptions. The description adds that the parameters 'cat' and 'interface' serve as filters, which provides context beyond the bare schema. However, it does not explain the expected values for 'cat' or the meaning of the enum options for 'interface', leaving partial ambiguity.

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

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

The description clearly states 'Parts list (filterable by classification/interface)', which specifies the verb (list) and resource (parts) and distinguishes it from siblings like parts_add, parts_get, or parts_search. It explicitly mentions filtering capability, making the purpose precise and differentiated.

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

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

No guidance on when to use this tool versus alternatives such as parts_search or parts_get. The description does not specify context, exclusions, or prerequisites, leaving the agent without decision-making support.

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?

Without annotations, the description discloses tombstone behavior for embedded parts but omits whether deletion is permanent for non-embedded parts, required permissions, or error conditions.

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

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

Single sentence with clear structure, front-loading the action and adding crucial behavioral detail without waste.

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?

Adequate for a simple 1-param tool, but lacks explanation of return value or error behavior, which would be expected given no output schema.

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

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

The only parameter 'id' is not described at all. With 0% schema coverage, the description should explain its format or purpose but does not.

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

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

The description clearly states the tool deletes parts and adds nuance about embedded parts using tombstone hidden state with re-add revival, distinguishing it from sibling tools like parts_add or parts_update.

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

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

No explicit guidance on when to use this tool versus alternatives like parts_update or parts_add. Lacks context about prerequisites or situations where deletion is appropriate.

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 disclose behavioral traits. It only states it searches by keyword but does not mention case-sensitivity, pagination, whether results are filtered, or any limitations. The behavior is minimally 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 description is a single, efficient sentence that immediately conveys the tool's purpose without any unnecessary 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 simple search tool with one parameter and no output schema, the description covers the core functionality. However, it lacks details on return value structure, pagination, or error states, which would be helpful for complete understanding.

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

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

With 0% schema description coverage, the description must compensate. It adds meaning by stating the query parameter is used for keyword searching in specific fields (model number, description, usage), but does not elaborate on syntax, wildcards, or multiple keywords.

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

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

The description clearly states the tool searches for parts by keyword, specifying the fields (model number, description, usage). It is a specific verb+resource combination and distinguishes from sibling tools like parts_get (single part) and parts_list (all parts).

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

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

The description implies usage for keyword-based searching but does not explicitly state when to use this tool versus alternatives like parts_get for specific IDs or parts_list for complete listings.

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

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

No annotations exist, so the description must disclose behavior. It implies read-only aggregation but does not explicitly state side effects, permissions, or if data is stale. For a stats tool, more transparency about data sources or refresh behavior would help.

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

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

The description is very short (one line) and to the point. It conveys the core function without extraneous words, fitting for a simple stateless tool.

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

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

Given no output schema, the description should detail the format or structure of the overview. It only mentions 'total/classification' but not whether it's a list, counts, or chart. Incomplete for an agent to use accurately.

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?

No parameters exist, so schema coverage is irrelevant. The description adds value by explaining the output purpose (total and classification breakdown), which is beyond the empty schema.

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

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

The description states it provides an overview of the parts catalog including total count and classification breakdown. This clearly indicates a summary/stats tool, distinguishing it from listing or search tools among siblings.

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

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

No guidance on when to use this tool versus alternatives like parts_list or parts_search. The description does not mention prerequisites, scenarios, 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 full burden of disclosing behavioral traits. While it mentions '上書きも可' (overwrite possible), it fails to disclose destructive potential, authorization requirements, side effects on related data, or whether updates are reversible. For a mutation tool, this is a significant gap.

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

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

The description is a single sentence with no filler, but it lacks structure (e.g., bullet points for parameters or behavioral notes). It is concise but could be more scannable.

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

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

Given the complexity of a mutation tool with 2 parameters (including a nested object), no output schema, and no annotations, the description is insufficient. It does not explain the return value, error conditions, or the scope of what 'embedded parts' means. For a tool here, more detail is needed for safe 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?

With 0% schema description coverage, the description should compensate by explaining the patch object's fields. It only hints at '価格/調達先' (price/supplier) which correspond to 'unit' and 'src', but does not clarify the 'id' parameter (probably the part identifier) or other fields like 'cat', 'desc', 'part', 'keywords', 'footprint', 'interface'. This leaves the agent guessing about the valid structure.

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

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

The description clearly states '既存パーツを更新' (update existing parts), which distinguishes it from sibling tools like 'parts_add' (add), 'parts_remove' (remove), and 'parts_get' (get). It also specifies an additional capability: overwriting prices/suppliers of embedded components, adding precision beyond the basic update 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?

The description implies usage for modifying existing parts but does not explicitly state when NOT to use it (e.g., for adding new parts, use 'parts_add'; for read-only lookups, use 'parts_get'). No alternative or prerequisite guidance is provided, leaving the agent to infer from sibling names.

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