TradesPro

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

Adds crucial behavioral qualifier 'likely' indicating probabilistic guidance rather than definitive determinations. Mentions output type ('guidance on common permit triggers'). However, with no annotations provided, lacks operational details on permissions needed, whether it queries live permit databases, or rate limit considerations.

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?

Efficient structure: two-sentence purpose statement followed by Args block. Examples are specific and illustrative without verbosity. Every element 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?

Appropriately complete for a single-parameter tool with existing output schema. Parameter is well-documented. Could improve by noting whether guidance is jurisdiction-specific or general, given that permit requirements vary by location.

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?

Completely compensates for 0% schema coverage. The Args section provides clear semantics ('plain-English description') and concrete examples ('replacing a kitchen faucet', 'adding a new 240V circuit') that are essential for the agent to construct valid 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?

Excellent verb-specific description: 'Check whether a described job likely requires a permit and inspection.' Clearly identifies the resource (permit/inspection requirements) and distinguishes from siblings like estimate_materials or lookup_building_code by focusing on regulatory triggers rather than materials or code text.

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 implicit domain scoping ('electrical, plumbing, and HVAC work') but lacks explicit when-to-use guidance versus similar tools like lookup_building_code or scope_job. No mention of jurisdictional limitations or prerequisites.

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

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

With no annotations provided, the description carries the full burden. It discloses the return value (material list and cost estimate) and valid input constraints via the enumerated job types, but omits behavioral details like calculation methodology, price freshness, regional applicability, or caching.

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

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

The description is appropriately brief with two distinct sections: purpose declaration followed by Args documentation. While the 'Args:' formatting is slightly unconventional for MCP descriptions, it efficiently delivers necessary information without redundancy.

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

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

Given the output schema exists, the description appropriately omits return value details. For a single-parameter tool, enumerating valid inputs provides adequate coverage, though it could strengthen context by referencing sibling `list_available_jobs` or noting prerequisites.

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 coverage and no enum defined in the JSON schema, the description provides crucial compensation by documenting the `job_type` parameter and enumerating all nine valid values (panel_upgrade_200a, ev_charger_install, etc.), effectively serving as the parameter documentation.

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

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

The description clearly states the tool 'Get[s] a material list and cost estimate' using specific verbs and identifies the resource (materials/costs) and domain (standard trade jobs). However, it does not differentiate from siblings like `lookup_material_price` or `scope_job`.

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

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

No guidance is provided on when to use this tool versus alternatives like `lookup_material_price` (which gets individual prices) or whether `scope_job` should be called first. The enumerated job types imply usage but do not guide selection.

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 disclosure burden; it establishes read-only nature via "List" and explains filter behavior. Missing pagination details and definition of "available" (system-wide vs. user-specific), but output schema partially covers behavioral contract.

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-part structure front-loads purpose (first sentence) followed by Args documentation; clear and appropriately sized, though the docstring-style "Args:" formatting is slightly informal for MCP context.

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 listing tool with output schema present, description provides sufficient context: clear purpose, complete parameter documentation with valid values, and implied read-only behavior. Absence of pagination limits is acceptable given the tool's straightforward filtering logic.

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

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

Schema has 0% description coverage, but description fully compensates by documenting valid enum values ("electrical", "plumbing", "hvac"), optional nature, and empty-string behavior (returns all jobs), effectively serving as the parameter documentation.

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?

"List all available job templates" provides specific verb (List) and resource (job templates), with "optionally filtered by trade" clarifying scope. It implicitly distinguishes from siblings like scope_job (templates vs. scoping) and estimate_materials (jobs vs. materials), though explicit differentiation from scope_job would strengthen further.

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 clear usage guidance for the optional "trade" parameter (leave empty for all results, or specify a trade filter). However, it lacks explicit guidance on when to select this tool versus siblings like scope_job or check_permit_requirements (e.g., workflow sequencing).

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the constraint that results are filtered by trade and limited to three specific values. However, it omits other behavioral traits like read-only safety, pagination behavior, or whether results are cached/real-time.

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 efficiently structured with the purpose statement front-loaded, followed by a clear Args section. Every sentence earns its place—no fluff or redundant filler. The formatting is clean and 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 simple single-parameter input and existence of an output schema, the description is reasonably complete. It successfully documents the parameter constraints. Minor gap: it could clarify the relationship to sibling tools, particularly that this is a prerequisite step before using 'lookup_building_code'.

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?

Excellent compensation for 0% schema description coverage. The Args section explicitly documents the 'trade' parameter, defines it as a trade type, and crucially enumerates the exact valid values ('electrical', 'plumbing', 'hvac') which the schema itself does not provide as an enum constraint.

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 verb (List) and resource (building code topics) with scope (for a given trade). However, it doesn't explicitly differentiate from the sibling tool 'lookup_building_code', which also deals with building codes but likely retrieves specific content rather than listing available topics.

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

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

The description implies usage context by specifying the trade parameter and its valid values, but provides no explicit guidance on when to use this discovery tool versus 'lookup_building_code' or the expected workflow (e.g., 'use this first to find topics, then lookup specific codes').

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 adds valuable scope constraint ('residential') not mentioned in the name, but lacks disclosure on data sources, versioning, read-only safety, or error handling when topics are invalid.

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?

Well-structured with purpose statement followed by Args block. The examples earn their place by providing necessary enumeration missing from schema. Slightly embedded format, but necessary given schema deficiencies.

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?

Complete for input parameters given output schema exists (no need to describe returns). Covers the two required parameters well. Could improve by mentioning jurisdiction handling or that trade/topic must align.

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

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

Schema has 0% description coverage (both properties undocumented), but the description compensates exhaustively by defining 'trade' with exact enum values and 'topic' with categorized examples for each trade type. Essential semantic meaning is fully captured in text.

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?

Clear verb ('look up') and resource ('residential building code requirements') with specific domain (electrical/plumbing/HVAC). Loses one point for not distinguishing from sibling 'list_code_topics' or 'check_permit_requirements'.

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 strong implied usage through the Args examples showing valid values for each trade, but lacks explicit guidance on when to use this vs 'list_code_topics' or what to do if requirements vary by jurisdiction.

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

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

Annotations are absent, so description carries full burden. Mentions 'current average' implying time-sensitive data, but fails to disclose caching behavior, price expiration, geographic scope, or error conditions (e.g., material 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?

Two distinct sections (description + Args) with no extraneous text. The examples are specific and helpful. Front-loaded purpose statement followed by parameter details is effective for quick comprehension.

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 single-parameter lookup tool with existing output schema (context signals confirm output schema exists, so return values needn't be described). However, gaps remain regarding sibling differentiation and behavioral details.

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% (no property descriptions), but the description fully compensates by defining 'item' and providing concrete search term examples ('wire', 'panel', 'pex', 'water heater'), saving the agent from guessing input format.

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

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

Clear verb 'Look up' and resource 'current average price for a specific material'. Missing explicit differentiation from sibling 'estimate_materials' (which likely calculates job costs vs. single item lookup), but specific enough to identify the tool's 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?

No explicit guidance on when to use this versus 'estimate_materials' or other lookup tools. Lacks prerequisites (e.g., whether material name must be exact) and 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?

No annotations provided, so description carries the burden. It discloses the output structure (what fields are returned) which helps understand the tool's behavior. However, it lacks details on side effects, caching, authentication requirements, or cost of the operation.

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?

Well-structured with purpose front-loaded in the first sentence. The Args section is necessary given the 0% schema coverage and efficiently packs the enum values. No filler 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?

With output schema available, the description appropriately summarizes return values rather than detailing them. It adequately covers the single parameter despite zero schema documentation. Only gap is explicit differentiation from 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% (no property descriptions), but the description fully compensates by providing the job_type parameter semantics and explicitly listing all 8 available enum values (panel_upgrade_200a, ev_charger_install, etc.) that the schema fails to define.

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 uses specific verb 'Get' with resource 'job scope' and lists exactly what is returned (labor hours, material costs, price range, permits, notes). This clearly distinguishes it from narrower siblings like check_permit_requirements (permits only) and estimate_materials (materials only).

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

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

No explicit when/when-not guidance comparing to siblings (e.g., 'use check_permit_requirements instead if you only need permit info'). However, the enum list in the Args section provides necessary context for usage.

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