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 discloses what gets analyzed (unverified/expired documents, open authority comments) and the risk categories, but never says whether the tool is read-only, whether it has side effects, or what happens if the permit does not exist — gaps that matter given annotations are absent.

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 front-loaded: the gate metaphor and scope appear before the Args/Returns boilerplate. The header line ('Blocker Breakdown Gate') is mildly redundant, but overall every sentence adds information about scope or output.

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, the description needn't spell out return values, and it still summarizes them (score, risk tier, blocker breakdown, actions). For a one-parameter read/analysis tool this is close to complete; only the safety/mutation profile and error behavior are 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 coverage is 0% for a single required string, so the description is the only source of meaning. It labels it a 'Permit identifier' and supplies a concrete example format ('P-1042'), which goes beyond the bare 'Permit Id' string property in 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?

States a specific verb (audits readiness), a specific resource (a single permit), and enumerates the concrete outputs (0–100 score, risk tier, blockers, Go/No-Go verdict). An agent can distinguish this from search_permit_requirements or estimate_permit_fees_and_sla purely from the description.

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 'pre-filing audit' and 'Pre-Submission Readiness Audit' imply the use context (before submitting a permit) but never state exclusions, prerequisites, or which sibling to use instead. Usage is inferable but not explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool estimates and returns an itemized breakdown, but it does not state whether it is read-only, deterministic, dependent on real-time data, subject to rate limits, or requiring authentication. Accuracy disclaimers and coverage limitations are also absent.

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 what the tool does, followed by structured Args and Returns sections. The leading phrase restates the tool name and is slightly redundant, but overall the content is tight and easy to scan. No unnecessary filler is present.

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

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

An output schema exists, so the description does not need to detail return values. It covers the three required inputs with examples and scope, and it names the supported cities. It lacks caveats about calculation accuracy or permit-type coverage, but it is otherwise sufficient for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does so reasonably well by explaining each parameter: jurisdiction with city examples, permit_type with trade examples, and valuation with its unit (USD). It does not enumerate all allowed values, but it provides clear semantic meaning beyond the bare schema.

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

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

The description states a specific verb and resource: estimates municipal permit fees, plan check surcharges, technology fees, and review turnaround timelines. It also names the supported jurisdictions (Phoenix, Scottsdale, Tempe, Mesa), which helps scope it. It does not explicitly differentiate from siblings, but the purpose is clear enough to distinguish it from search and readiness 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?

The description explains what the tool does but offers no explicit guidance on when to use it versus alternatives. There is no mention of prerequisites, exclusions, or related sibling tools. Usage is only implied by the tool name and description.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one genuinely valuable behavioral trait — an explicit Human-in-the-Loop PE verification gate before municipal upload — but says nothing about permissions, idempotency, whether generation is re-runnable, or side effects on the permit record.

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 opening sentence is front-loaded and the workflow constraint follows immediately. The Args/Returns block is somewhat boilerplate and the Returns line partly restates what the output schema already declares, but it is short enough that no sentence is wasteful.

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

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

For a single-parameter generation tool with an output schema present, the description supplies the triggering context, the core workflow (objection resolution with citations), and the critical PE gate. The main missing element is what happens on failure or what a generated packet requires as follow-up input.

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% for the single parameter, so the description must compensate. It identifies permit_id as a 'Permit identifier' and supplies a concrete example format ('P-1042'), which is meaningful guidance beyond the bare string type in 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?

States a specific verb+resource: compiling a Comment-by-Comment Transmittal Letter that resolves examiner objections with code citations and revision clouds. It is clearly distinct in kind from the sibling tools (intake, fee estimation, search, readiness checks), though it never names a sibling to differentiate against.

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 context is implied rather than stated: the tool operates on examiner objections and must run before municipal upload, with a PE verification gate. There is no explicit 'use this when / not when' or reference to alternative tools, so the agent must infer the trigger condition.

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 it aggregates (portfolio health, overnight status transitions, expiring contractor insurance) and what it emits (health score, key changes, bottlenecks, task matrix). It does not state whether the call is read-only, how expensive/latent such a synthesis is, or any caching 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?

Purpose is front-loaded and the example utterances earn their space by making intent matching easy. There is mild redundancy between the synthesis sentence and the Returns block, which both restate portfolio health, bottlenecks, and the task list.

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 and zero parameters, the description need not explain return structure in detail, and it still summarizes the report contents adequately. Purpose, trigger contexts, and synthesis scope are all covered, so an agent has everything it needs to invoke this correctly.

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

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

The tool takes zero parameters, so there is nothing to document and the schema cannot be the source of ambiguity. Baseline 4 applies; the description adds no parameter guidance because none is required.

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

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

The description opens with a specific verb+resource ("Generate the daily executive briefing and prioritized action plan for permit managers") and then enumerates the exact inputs it synthesizes. It is clearly distinguishable from every sibling, which cover intake, fee estimation, requirement search, readiness checks, AHJ packets, and contractor verification.

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 concrete trigger contexts ("during morning standups or management planning sessions") plus three example user utterances, which is strong routing guidance. It stops short of the top score because it never states when NOT to use it or names an alternative sibling to prefer in adjacent situations.

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 discloses a high-level multi-step workflow and says it returns a structured intake summary, but it does not explain side effects, whether the draft permit is persisted, permission requirements, or whether the tool is limited to Arizona projects.

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 tool identity and purpose, then organized into Args and Returns sections. It is somewhat long, but the length is justified by the multi-step domain and the need to compensate for missing schema descriptions.

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

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

Because an output schema exists, the description does not need to fully explain return values, and it does provide the parameter details missing from the schema. However, for a complex intake tool with no annotations, it omits important context such as geographic limitations, persistence/side effects, and how it should be sequenced with sibling permit 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?

Schema description coverage is 0%, but the description's Args section compensates by documenting all four parameters with examples and meaning: a plain-language SOW, a physical jobsite address, valuation in USD, and an optional project name. It does not add validation constraints, but the parameter semantics are substantially clarified 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 states a specific multi-step verb and resource: it parses contractor SOWs, determines AHJ jurisdiction, identifies trade sub-permits, verifies Arizona PE stamping thresholds, and scaffolds a draft permit. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as search_permit_requirements or check_permit_readiness.

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 by the name and the intake-oriented purpose, but there is no explicit when-to-use guidance and no named alternatives among the sibling tools. An agent can infer this is an initial intake/scaffolding step, but the description does not state when not to use it or how it relates to the other permit tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses the engine type (local, section-aware RAG), the sources covered, and a token-reduction figure, which is genuine behavioral context. It omits safety/mutation profile (implied read-only), latency, accuracy, and freshness/update behavior, leaving meaningful gaps for a zero-annotation tool.

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

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

The Args/Returns structure is clean and front-loads the purpose, but there is waste: the 'Rule 3' tag is unexplained and the '82.9% context token reduction' claim is marketing rather than actionable for an agent. Reasonable size overall, but not every sentence earns its place.

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

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

An output schema exists, so return-value detail is largely duplicated, but the description still adds useful framing (citations, section numbers, relevance scores, excerpts). Combined with full parameter coverage, an agent has enough to invoke the tool correctly. Only the interaction with sibling tools is left 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%, so the description must compensate, and it does: all four parameters are annotated with purpose, examples, and the top_k default. It explains that jurisdiction and permit_type are filters and what each controls. Coverage is strong, though enum-like values are only loosely suggested rather than enumerated.

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 and resource: a section-aware RAG search over municipal building codes, amendments, and technical guidelines, with concrete domain examples (Phoenix Mechanical Code 301.5, ASHRAE 90.1, NEC 2023). This is unambiguous about what the tool does. It does not, however, contrast itself against any sibling tool, so it stops short of a 5.

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

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

Usage is only implied: the query examples show the intended context (structural calculations, jurisdiction/permit filters) but there is no explicit 'use this when / not when' statement and no alternatives named among the sibling tools. An agent can infer the use case but must decide on its own when this search is the right call versus, say, check_permit_readiness.

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 disclose meaningful scope details — ROC standing, trade classifications, $1,000,000 GL policy expiration dates, and municipal Additional Insured endorsements — and 'Audits/verifies' implies a read-only operation. However it says nothing about data sources, latency, freshness of ROC records, or failure modes when a contractor 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?

The one-line audit summary is well front-loaded, and the Args block earns its place given 0% schema coverage. The Returns section, however, is largely redundant because an output schema already exists and the description only says 'structured compliance verification report' without adding detail.

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, the description needn't explain return values, and it adequately conveys the audit's scope across license and insurance dimensions. The main missing piece is operational context — when in a permit workflow to run the check and what happens on non-compliance.

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 only supplies bare titles. The description compensates well by giving a definition and a concrete example for each of the three parameters (contractor name, city jurisdiction, trade permit type), which is essential to calling the tool correctly. Minor gap: no format constraints for jurisdiction strings.

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: audits Arizona ROC standing and verifies trade classifications plus $1M GL insurance and endorsements. This is clearly distinguishable from sibling tools like search_permit_requirements or estimate_permit_fees_and_sla, which deal with permit rules and costs rather than contractor compliance status.

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 never says when to invoke this versus alternatives, nor what prerequisites exist (e.g. must a permit application already exist?). The presence of jurisdiction and permit_type hints at a pre-permit screening context, but this is left entirely to inference.

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