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

Annotations already declare it as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it returns records with reason, agency, and dates, and mentions partial match for name. It aligns with the annotations and goes beyond them by explaining the data returned. No contradiction.

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 concise yet thorough. It front-loads the main purpose, then gives usage scenario, then bullets the parameters, and finally mentions what is returned. Every sentence earns its place with no redundancy. Structure is clear 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 output schema exists (as per context) and annotations cover safety, the description provides sufficient contextual info: what it checks, when to use it, what inputs to provide, and what output to expect. It omits less critical details like pagination or error handling, but those are not essential for correct invocation.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. It does: name (partial match), uei (same identifier as other tools), cage_code (CAGE code). It also implies limit is optional via the 'at least one of' instruction, though limit itself is not explicitly described. This provides significant 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 clearly states the tool checks the SAM.gov exclusions list (debarred/suspended entities). It uses a specific verb ('Check') and resource ('SAM.gov exclusions list'), and the mention of identifiers shared with search_companies/search_entities distinguishes it from sibling tools. No ambiguity about what the tool does.

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 explicit when-to-use guidance ('before subcontracting or teaming, and again periodically post-award'). It also explains the required identifier input (at least one of name/uei/cage_code). However, it does not explicitly state when this tool should NOT be used or name alternative tools for related searches (e.g., general company search), so it lacks a clear exclusionary contrast.

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 already declare readOnly/openWorld/idempotent/non-destructive, so the bar is met by adding meaningful context: this tool is free on every plan, returns office-level win facts, and office_code occupies its own namespace with no shared identifier links out. This disclosure helps an agent reason about data scope and plan access beyond the annotations.

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 organized with a concise lead sentence, a short 'when to use' paragraph, a bulleted parameter list, and a follow-up note. Every sentence earns its place, though the opening paragraph is slightly verbose and could be tightened without losing meaning.

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?

Combined with the annotations and output schema, the description covers the tool's purpose, parameter semantics, return fields, usage context, follow-up tool, and access/namespace caveats. An agent has enough information to select and invoke this tool correctly and interpret its results.

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 fully compensates by documenting each parameter: NAICS is required with a 2-6 digit range and example, sort options are defined with their ordering logic, and limit has a max of 100. This exceeds the bare schema by giving actionable semantic meaning.

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 states a specific verb ('find'), resource ('contracting offices'), and dimension ('buy a NAICS code') with ranked results. It explicitly contrasts itself with department-wide averages and names a sibling tool (get_office_profile) for cross-NAICS analysis, making it easy to distinguish from related 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?

Clear use case is given: 'who actually buys this, not just which department' and explains why office-level ranking matters. It points to get_office_profile as the follow-up for full office-level analysis, though it does not explicitly enumerate when-not-to-use scenarios or alternatives with the same depth.

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?

Beyond the readOnly/idempotent annotations, the description adds useful behavior: a possible 503 while the market index is building, the nuance that `setaside_pct` aggregates across ALL families, and that `family_share_pct` is populated only when `set_aside_family` is set. This gives an agent accurate expectations for transient failures and per-family sorting semantics.

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 purpose and usage condition, then organized into a clear bullet list of parameters. It is longer than average but the length is justified by the 0% schema coverage; every major section contributes. The sort_by bullet is a bit dense but still 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?

Given 10 parameters, no schema-level descriptions, and an output schema, the description is largely complete: it explains entry-point usage, key parameter semantics, return guidance, and a transient failure mode. It does not cover limit/offset/sort_order, but those are minor conventional parameters, so the overall picture is strong.

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 carries the burden and documents most parameters well: sector, prefix, min_market, max_competitors, set_aside_family, keywords, and sort_by, including valid enum values. However, `limit`, `offset`, and `sort_order` are not explained in the description, leaving a minor gap even though their names and defaults are fairly self-explanatory.

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 and resource: 'Discover NAICS codes by current federal spending and small-business set-aside leverage.' It clearly positions itself as the entry point into the NAICS/Market Pulse tools and names the downstream tools, distinguishing it from siblings like get_naics_market and get_naics_competition.

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

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

It explicitly says to use this tool 'when you don't already know which NAICS code to look at,' which gives a clear condition for use. It also describes passing the resulting `naics_code` to downstream tools, but it does not explicitly state 'use get_naics_* directly if you already know the code,' so the alternative-usage guidance is strong but not fully 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?

While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds critical behavioral details: it notes that rows have a `notice_id` only for `source: "sam_award_notice"` rows, that FPDS-sourced rows have null notice_id, and that the tool is paginated. This goes well beyond the annotations and gives the agent important reasoning context about data provenance.

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 tightly structured: a purpose statement, a one-line access note, a bullet-style list of the key parameters, and then a short paragraph about the special `notice_id` behavior. Every sentence adds value without repetition, and the most important information is front-loaded.

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 covers the tool's action, scope, pagination, parameter details, and the critical edge case of `notice_id` being null for FPDS rows. The output schema handles return formatting, so the description needn't describe fields. It also relates to sibling get_opportunity. This is complete for an agent to call 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 explains `uei`, `sort_by`, `sort_order`, and `limit` with allowed values and constraints (max 1000). However, it omits `offset` entirely, which is a parameter in the schema. Since the tool is explicitly paginated, offset is important and its absence in the description is a minor 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 states a specific verb ('Get'), a precise resource ('full paginated award history for one company'), and explicitly differentiates from the sibling get_company_profile by noting it returns every individual award, not summary totals. This makes the tool's purpose unambiguous and easily distinguishable.

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

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

The description clearly indicates when to use this tool (when you need the full award history for a single company) and even points out the alternative (get_company_profile for summary totals). It also notes the Pro-only restriction. However, it doesn't explicitly mention when not to use it or list other alternatives like search_awards, but the primary distinction is clear.

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?

Beyond the read-only/idempotent annotations, the description discloses two non-obvious behaviors: SAM registration agents are filtered out, and the tool is rate-limited more tightly than other tools with separate IP and key burst limits. These are exactly the behavioral details an agent needs to avoid misuse and interpret results correctly.

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 longer than a two-liner but every section adds distinct value: purpose, sibling distinction, parameter format, and rate-limit warning. It is well structured with a bullet and line breaks, though the prose around the filtering behavior could be tightened.

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

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

For a single-parameter, read-only lookup with an output schema present, the description covers purpose, parameter format, licensing/access, and operational constraints. Nothing material is missing for an agent to decide when and how to invoke it correctly.

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

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

The schema provides only uei with a generic string type, so the description must compensate for the 0% schema description coverage. The bullet 'uei: 12-character Unique Entity ID' supplies the missing format/length meaning and is sufficient for selecting the correct value for the single 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 a specific verb and resource: resolving a vendor's actual decision-maker contact, and explicitly distinguishes the buyer side from search_contacts and the vendor/teammate side. It also names the SAM paperwork-filer filtering behavior, so an agent knows exactly what this tool returns.

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

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

It explicitly names search_contacts as the alternative for contracting-officer/agency-side contacts, making the selection condition clear. It also adds a practical rate-limit warning advising against tight loops across many UEIs, which functions as a when-to-avoid guideline, plus the Pro-only restriction.

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 already cover read-only, idempotent, and non-destructive behavior. The description adds access context (Pro only) and output behavior (returns each peer's uei, intended for chaining), which goes beyond the schema and annotations. No contradiction with annotations.

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?

Every sentence earns its place: purpose, usage distinction, parameter notes, and output chaining. It is compact, front-loaded with the core action, and free of filler.

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 two-parameter read tool with an output schema, the description covers access level, parameter constraints, return shape, and relationship to sibling tools. Nothing necessary for a correct call is missing.

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 documents uei as a 12-character Unique Entity ID and limit as max 50, adding useful constraints not present in the schema. Limit's default is already in the schema, so no need to repeat it.

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 states a specific action ('Find companies similar to this one') and defines the matching logic (NAICS + agency overlap). It explicitly contrasts with get_company_profile and search_companies, making the tool's role in the family 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?

Provides the exact question the tool answers and names two alternative tools with their different purposes, so an agent knows when to use this one. The Pro-only restriction is also a clear usage 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?

Annotations already provide readOnly/openWorld/idempotent hints. The description enriches this with a crucial scope note: totals count only SAM Award Notices (10-30% of federal obligations), not FPDS data, and a contractor active only in FPDS shows zero by design. This is significant behavioral context beyond annotations, with no contradiction.

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 clear sections: purpose, usage guidance, parameter details, and scope note. The length is justified by the critical scope caveat; every sentence adds value. The bold and bullet formatting enhances scanability without bloat.

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 tool with rich annotations and an output schema, the description covers purpose, alternatives, parameter semantics, and a subtle data-scope pitfall. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description fully compensates. It defines 'uei' as a 12-character Unique Entity ID and gives concrete sources (search_companies, search_opportunities' award_uei_sam, or any tool returning a uei field). This adds meaning beyond the bare string type.

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 ('Get'), resource ('company's aggregate profile'), and lists the included data (SAM registration fields + award-history totals). Explicitly distinguishes from get_company_awards and get_company_peers, leaving no ambiguity about what this tool does.

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?

Clearly indicates this is the SUMMARY view, names the alternatives for detailed awards and peers, and adds a licensing constraint ('Capture & Teaming tool, Pro only'). Provides both when-to-use and when-not-to-use guidance with explicit sibling references.

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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses the response shape: top-level sibling keys (`contract`, `transaction_rollup`, `subaward_rollup`), the fact that subaward_rollup is Pro-only, and the important edge case that a legitimate `subaward_count: 0` means no subs, not an error. This adds behavioral context that annotations do not provide, without any contradiction.

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 somewhat long but efficiently packed: the core purpose is front-loaded, then usage alternatives, then parameter guidance, and finally response structure. Each section earns its place. It could be slightly tightened, but it remains well-organized 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 a single required parameter and the presence of an output schema (which handles full return details), the description provides everything necessary for correct invocation: purpose, alternative tools, piid source, top-level response keys, and caveats (Pro-only subaward_rollup, zero-count meaning). No critical context is missing.

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

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

Schema description coverage is 0% and the only parameter `piid` is merely typed as a string. The description compensates by explaining that piid is the 'award PIID' and listing its possible sources (search_contracts, search_recompetes, or a company's award history). This gives the agent a clear understanding of what value to supply, far exceeding the schema alone.

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

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

The description states a specific verb ('Get'), a specific resource ('one contract's LATEST transaction'), and the summary roll-up of totals. It explicitly names sibling tools (get_contract_modifications, get_contract_vehicle) and clarifies this is the 'SUMMARY view', making the tool's purpose unambiguous and distinguishable from alternatives.

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 provides explicit guidance on when to use this tool versus alternatives: 'for every individual modification row use get_contract_modifications; for what vehicle it's under use get_contract_vehicle.' It also tells the agent where the piid comes from (search_contracts, search_recompetes, or a company's award history), giving clear context for invocation.

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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds critical behavioral context: the data only covers FY2025 onward, so history may start mid-sequence, and earlier modifications are 'never ingested, not filtered out'. It also tells the agent to check the response's 'window' block for clamped/earliest_searchable/reason. This goes well beyond annotations.

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 well-structured and information-dense: core purpose in the first sentence, data caveat and response guidance in the second paragraph, then a bullet list for parameters. Every sentence earns its place with no fluff.

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 tool is complex due to its data completeness caveat and window block, and the description addresses both comprehensively. An output schema exists, so return values need no explanation. Offset is the only minor omission, but the rest of the context is complete for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains piid as 'award PIID' and limit as 'max 500', adding practical constraints not in the schema. However, the offset parameter is not described, leaving a small gap given the zero coverage baseline.

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 ('Get EVERY transaction row'), a resource ('contract'), and explicitly distinguishes itself from the 'latest snapshot get_contract gives you'. It names the sibling get_contract and clarifies the difference, making the tool's purpose 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?

The description clearly indicates when to use this tool: when you need the full modification trail rather than the latest snapshot. It contrasts with get_contract and provides important context about no per-request date filter. However, it does not explicitly say when NOT to use it or list alternative sibling tools beyond get_contract.

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 already signal read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: the standalone edge case with `{status: "standalone", vehicle: null, message: ...}`, the instruction to check `status` before accessing fields, and the fact that it returns the vehicle's own PIID rather than the order PIID.

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 structured with a one-sentence definition, a category tag, a clear bullet for the parameter, and a compact edge-case paragraph. Every sentence adds necessary information, and code formatting makes the special return case easy to parse.

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 a single required parameter, a clear edge case, sibling routing, and an output schema present, the description is complete. It explains the input source, the semantic distinction between order PIID and vehicle PIID, the standalone fallback, and what downstream tools to chain into—nothing needed for correct use is missing.

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 for piid is 0%, so the description carries full responsibility. The bullet explicitly defines piid as 'the ORDER's PIID (not the vehicle's own PIID)' and says where to obtain it, which is exactly the kind of disambiguation needed for correct 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 opens with a specific verb and resource: 'Get the contract vehicle (IDIQ, GWAC, FSS schedule, or BPA) this order was placed against.' It clearly distinguishes itself from siblings by noting the input is the ORDER's PIID and that get_vehicle/get_vehicle_holders are for downstream detail, so an agent can instantly tell this tool apart.

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 explicit routing guidance: use get_vehicle for the vehicle's own ceiling/period detail and get_vehicle_holders to see competitors. It also tells the agent when NOT to read vehicle fields—when status is 'standalone'—and states the PIID source (search_contracts or get_contract), leaving little to inference.

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

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

Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds useful context beyond annotations: it is Pro-only, returns UEI identifiers, and sets practical expectations via the limit cap. This is meaningful behavioral information for an agent deciding whether to call the 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 description is well-structured and appropriately sized. It leads with purpose, gives the practical use case, then follows with a concise bullet list of parameter semantics. No redundant 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?

The description covers purpose, usage context, parameter semantics for most arguments, and the chaining workflow. Given the annotations and output schema, the main missing piece is the offset parameter's meaning, but the rest is sufficiently complete for correct selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It provides valuable semantics for within_days (range and default), state/naics (optional filters), and limit (maximum). However, it omits the offset parameter entirely, which is a gap for pagination understanding.

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 and resource: 'Find SAM registrations expiring within N days.' It also explicitly frames this as a 'monitoring/list question' and distinguishes it from a name lookup, so an agent can understand what this tool is for and how it differs from entity lookup 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?

The description gives clear when-to-use guidance: monitoring expirations, self-monitoring, and checking teammates/subs. It contrasts the tool with 'a name lookup' and recommends chaining to get_entity for full records, though it doesn't name the exact alternative tool for name lookup.

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 already include readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the return shape is the same whether using UEI or CAGE, and that it is the 'full registration record'. It also notes the free tier limitation. These add context beyond the annotations without contradicting them.

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 compact, front-loaded with the primary purpose, and uses bullet points for parameter usage. Every sentence serves a purpose: scoping, parameter clarification, and tier/return-shape note. No redundant filler.

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 2-parameter read tool with output schema present, the description covers the key operational detail (exactly one identifier) and data sources. It does not explain error scenarios (e.g., what happens if both or neither are provided) or pagination/limits, but given the tool's simplicity and the presence of an output schema, it is largely complete. Minor gap around validation behavior prevents a 5.

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

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

Schema provides only names and nullability with 0% description coverage. The description compensates by explaining the format of `uei` (12-character) and the source of `cage_code` (from a contract/award record's `cage_code` field), and explicitly requires exactly one of them. This is meaningful semantic guidance 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?

Description explicitly states 'Get one SAM entity's full registration record by UEI or CAGE code' – specific verb (get), resource (SAM entity registration record), and scoping (by UEI or CAGE code). It also clarifies the relationship between the two identifiers ('the same question, two different keys') and that it is a single tool, distinguishing it from possible separate 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?

Provides clear when-to-use guidance: 'Provide exactly one of `uei` or `cage_code`.' It also explains where those values come from (search_entities, search_companies, contract/award records), and notes that the free tier is Developer. Though it doesn't list alternatives to avoid, the instruction to provide exactly one key and the source field routing is explicit enough for correct invocation.

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 already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail: data source (GSA CALC), what the response contains (rate_distribution, escalation, etc.), and importantly explains how `value_basis` differs from get_price_benchmark's enum. It also clarifies that escalation is a real median YoY growth, not a guessed flat 2-3% escalator.

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 dense but efficiently organized: a purpose statement, a usage note, and a bulleted parameter list with inline value explanations. Every sentence adds information, and the structure makes scanning easy.

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 12 parameters, the description covers all of them, explains the response components, and provides the context needed to invoke the tool correctly. The presence of an output schema further reduces the need to document return details, yet the description still summarizes key fields.

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 fully compensates by defining every parameter's meaning, allowed values, and even examples (e.g., labor_category example, min/max experience 0-60, value_basis distinct enum). It goes beyond the schema by explaining the 'SIN bridge' for naics and how `vendor` should be used.

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 ('Get') and a precise resource ('awarded labor-rate (should-cost) benchmark for a labor category, from GSA CALC'), and explicitly contrasts it with get_price_benchmark, making the tool's unique role unmistakable.

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

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

The description gives clear context for when to use the tool ('the labor-cost input for a proposal', 'Bid & Proposal / Negotiate tool') and shows how to use `vendor` with search_companies for competitor lookup. It doesn't explicitly state when not to use it or alternatives beyond the pairing mention, but the guidance is strong.

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 already declare readOnly/openWorld/idempotent/non-destructive. The description adds valuable behavioral specifics: 'Free tier. Factual, never scored,' the 404 condition for no activity in the last 12 months, and the scope 'over the whole FPDS prime-award market.' These go beyond the annotations and inform the agent about cost, error handling, and data source.

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 longer than typical but every sentence contributes: it starts with the core purpose, then details the metrics, then differentiates from siblings, then lists the parameter, then notes free tier and 404 behavior. The structure is logical and front-loaded with the most important information, though it could be slightly trimmed without losing 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 the tool's complexity (multiple returned metrics), the description is complete: it tells the agent what data to expect, the parameter format, the error condition, and the free/factual nature. An output schema exists, so the description doesn't need to enumerate return fields. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains the 'code' parameter as '2-6 digit NAICS code,' which clarifies the expected format. For a single required parameter this is adequate, though it could have included an example or validation notes. The description adds meaning beyond the schema's bare 'string' type.

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 pair: 'Get how contested a NAICS market is,' and enumerates the concrete metrics returned (offers per award, single-bidder share, etc.). It explicitly distinguishes itself from three sibling tools by naming them and their differing focus, leaving no ambiguity about what this tool does.

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

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

It explicitly names alternatives (get_naics_market, get_naics_simplified_acquisition, get_naics_positioning) and states what each covers ('size + concentration,' 'small-buy value bands,' 'the language'), telling an agent when to choose this tool (for contestability) and when to use others. The context of a 'Market Research / Capture tool' further guides appropriate 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?

The read-only and idempotent annotations are reinforced with concrete runtime behavior: 400 for invalid board names, 503 while the market index is building, and the fact that results carry a naics_code intended for downstream tools. This adds meaningful behavioral context beyond the annotations.

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 compact and uses a clear structure: an intro sentence, a distinction sentence, bullet-style parameter notes, and a short return/error note. There is no filler or redundant restating of the schema.

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

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

For a two-parameter read-only tool with an output schema, this description covers permitted values, limit constraints, return usage, and error conditions. The agent has enough information to select and 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 schema has no descriptions and no enums, so the description carries the full burden. It explicitly enumerates every accepted board value and caps limit at 100, giving an agent exactly what it needs to construct valid arguments.

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 browses curated, ranked NAICS market leaderboards and explicitly distinguishes it from find_naics_codes' open filtered search. The 'fixed set of named rankings' phrase further sharpens what this tool does.

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 names the key alternative, find_naics_codes, and draws a clear boundary: curated fixed rankings here versus open filtered search there. It also directs the agent to pass returned values to get_naics_market or downstream NAICS tools, giving useful routing 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?

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses that size_standard will be null with status 'pending_sba_table', warns not to rely on the response for SBA small-business eligibility, notes the free tier, and specifies the 404 condition for no FY2025+ contract activity. No contradiction with annotations.

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 well-organized and every sentence serves a purpose: definition, sibling differentiation, parameter format, data caveat, and error behavior. It front-loads the core function before the caveats and keeps the structure scannable with line breaks and bullet-style 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?

Given the output schema exists and the tool has one parameter, the description covers everything an agent needs to call it correctly: input format, sibling alternatives, data limitations, error condition, and operational context. No critical behavioral or usage detail appears to be missing.

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 the key format constraint '2-6 digit NAICS code', which is meaningful, but it does not provide examples, validation rules, or guidance on formatting beyond the digit range. The single parameter is minimally but not richly described.

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 opens with a specific verb and resource: 'Get the federal market profile for one NAICS code' and enumerates the exact contents (spending, competition, set-aside leverage, top buyers, top incumbents). It also distinguishes itself from get_naics_positioning by framing this as the AWARD side versus the SOLICITATION side.

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 explicitly names sibling tools and the conditions for pairing: get_naics_positioning for solicitation language, get_naics_simplified_acquisition for small-buy value bands, and get_naics_competition for deeper contestability. It also tells the agent when a 404 will occur, which is a direct usage signal.

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 already declare readOnly, openWorld, idempotent, and destructive=False, and the description adds meaningful behavioral context: the 24-month lookback over SAM opportunities, the free tier, and the 404 error when no activity exists. This goes well beyond the structured annotation fields.

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

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

The description is front-loaded with the core purpose and outputs, then gives usage context, pairing advice, parameter format, and error behavior. Every sentence earns its place, and the structure is scannable despite carrying a lot of useful 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 tool with an output schema already present, the description supplies everything needed to call it correctly: what it returns conceptually, the time window, the data source, the error case, and the intended use. No critical operational detail is missing.

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 only provides a bare 'code' string with no description, and schema description coverage is 0%. The description compensates by specifying that the code must be a 2-6 digit NAICS code, which is important format guidance. It could have added a concrete example or clarified digit-only format, but it adds meaningful semantic value.

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: getting the language and set-aside makeup for a NAICS code's solicitation side. It enumerates concrete outputs (phrase vocabulary, set-aside share, top soliciting agencies) over a defined window, and explicitly distinguishes itself from get_naics_market by calling out the award side. This is fully differentiated from the large sibling set.

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 clearly frames the tool as a Market Research / Capture tool and tells the agent exactly what the data is for: building a SAM/DSBS profile or capability statement. It also names get_naics_market as the complementary tool for the award side. It does not explicitly enumerate exclusions against other NAICS siblings, but the usage context is strong enough to 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?

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description discloses the 404 behavior when no FPDS prime-award activity exists, the time window, the output's factual/not-scored nature, and the explicit absence of a recommendation. This adds substantial behavioral context without contradicting annotations.

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 well-structured: it front-loads the core output, then provides usage context, parameter format, and edge-case behavior. It is longer than strictly necessary, with the FAR legal citation and policy explanation being helpful but not essential for invocation, yet no sentence is wasted.

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

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

With a single parameter, annotations, and an output schema present, the description covers the remaining needed context: exact data returned, time window, sibling relationship, 404 failure mode, and the tool's advisory limitations. An agent has everything needed to select and call this 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 schema provides only a required 'code' string with 0% description coverage, so the description carries the full burden. It specifies 'code: 2-6 digit NAICS code,' giving the format and domain meaning. For a single-parameter tool, this is adequate, though a concrete example or leading-zero note would have made it complete.

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: it gets the award-value breakdown for a NAICS code over the last 12 months of FPDS prime awards, including counts by award band, offices, distinct firms, and set-asides. It clearly differentiates itself from siblings by labeling itself the 'SMALL-BUY value-band read' within the Market Research tool family.

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 explicitly positions the tool as the simplified-acquisition band read and names two sibling tools to pair with for related contexts: get_naics_positioning and get_naics_market. It also provides a FAR Part 13 context that clarifies when this band is relevant, giving an agent clear routing guidance.

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

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

Beyond the provided annotations (readOnly, openWorld, idempotent, non-destructive), the description adds meaningful behavioral detail: the tool is free on every plan, returns 404 when no FPDS activity exists for the office, and returns 503 while the index is building with a retry hint. This enriches the agent's expectations without contradicting the annotations.

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's core purpose, then moves to usage context, parameter guidance, and error behavior in a logical order. Every sentence adds actionable information, and there is no redundant filler.

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

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

For a single-parameter, read-only tool with an output schema and rich annotations, the description covers everything needed to invoke it correctly: what it returns conceptually, when to use it, how to obtain the parameter, and what errors to expect. The existing output schema obviates the need to detail return fields.

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 carries the burden for the single parameter. It explains that office_code is the FPDS office code and where to obtain it (discover_offices or a contract/award record), which goes beyond the bare schema. It stops short of specifying format or example values, so it is helpful but not exhaustive.

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 precise verb-resource pair: 'Get one contracting office's full buying profile' and enumerates the contents (obligations, competition, set-aside lean, NAICS). It also distinguishes this tool from single-NAICS tools by emphasizing the ENTIRE buying pattern, making sibling differentiation clear.

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

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

The description clearly states when to use the tool: after discover_offices or when an office_code is already known from a contract/award record. It contrasts the scope against per-NAICS analysis, giving useful context, though it does not explicitly name an alternative tool or provide a direct when-not-to-use statement.

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 already convey that the operation is read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context by specifying what the returned record includes, such as agency, contacts, attachments, and award data where applicable.

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 concise sentences lead with the core action and lookup key, then summarize the returned payload. There is no filler or unnecessary repetition.

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

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

Given the simple one-parameter input, the presence of an output schema, and annotations that cover the safety profile, the description provides enough context for correct invocation. The summary of returned fields is a helpful supplement beyond the 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?

With 0% schema description coverage, the description must compensate for the single parameter. It clarifies that notice_id is the identifier used to fetch a specific opportunity, but it does not provide format, examples, or guidance on where to find the ID. The basic semantic is adequate, though not deeply detailed.

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

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

The description uses a specific verb ('Fetch'), names the resource ('single contract opportunity'), and identifies the lookup key ('notice_id'). This clearly distinguishes it from sibling search tools like search_opportunities, which return multiple results.

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

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

The description clearly states this is the tool to use when fetching one contract opportunity by its notice_id. It does not explicitly name alternatives or state when not to use it, but the lookup-by-ID context is unambiguous.

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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds meaningful behavioral context: it explains the one-call inclusion of relationships, discloses the free tier, and specifies the 404 error for nonexistent IDs. No contradictions with annotations.

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 organized: the core purpose is front-loaded, followed by use-case differentiation, a parameter hint, and error behavior. Every sentence provides value with no redundancy or fluff.

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 presence of an output schema, the description need not explain return values. It covers the parameter source, the alternative tool, the error case, and the relationship scope, making it complete for an agent to call 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 integer parameter with 0% description coverage, so the description must compensate. It does by pointing the agent to list_organizations as the source of a valid organization_id, which is a practical and actionable hint. It doesn't over-explain since the meaning is largely carried by the tool name and context.

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

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

States a specific verb ('Get'), a clear resource ('federal organization's full record'), and enumerates exactly what is included (parent, immediate children, full ancestor chain). It also explicitly differentiates itself from get_org_relationships, so an agent can distinguish them without reading the other schema.

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

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

Provides explicit routing: 'use this first' and only call get_org_relationships when the narrower subset is needed, with a concrete example. Also tells the agent that organization_id comes from list_organizations, covering the prerequisite.

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 already cover read-only, idempotent, non-destructive behavior. The description adds useful behavioral details beyond that: the 404 condition for the ancestors direction when organization_id doesn't exist, and the fact that ancestors returns an empty list for a root department. It also clarifies 'children' means immediate sub-organizations, which is a meaningful scope constraint.

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?

Every sentence earns its place: scope, sibling differentiation, a decision example, then a tight bulleted param breakdown and error condition. No filler, no repetition of annotations, and important details are front-loaded.

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 two-parameter tool with an output schema and strong safety annotations, the description covers the core use case, parameter meanings, valid directions, edge cases, and error behavior. Nothing material an agent would need to call it correctly is missing.

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 carries full responsibility. It delivers: organization_id provenance from list_organizations or get_organization, and an explicit enumeration of direction's valid values with their precise meanings and an edge case for root departments. This fully compensates for the lack of schema descriptions.

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

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

The description states a precise verb and resource: 'Get JUST an organization's immediate children or its ancestor chain.' It explicitly narrows the scope, saying this is without the rest of the record, and names get_organization as the tool that includes more. This differentiates it clearly from even a large sibling set.

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 explicit when-to-use context: use this for a narrow result when the full record is unnecessary. It names get_organization as the alternative if 'you need everything,' and provides a concrete DoD sub-agency example that operationalizes the decision.

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?

Beyond the readOnly and idempotent annotations, the description exposes non-obvious behaviors: raw single-letter FPDS codes can appear as passthrough data ('not an error'), date filters apply to action_date rather than award date, and combined is 'blended context only, not a real number to price against.' These are exactly the behavioral quirks an agent needs.

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?

Although long, the description is front-loaded with purpose and usage, then structured parameter guidance, then a critical caveat. Every sentence earns its place; the length is justified by 8 parameters, multiple sibling tools, and important behavioral warnings.

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 is fully complete for a complex, 8-parameter tool with 0% schema coverage. It covers when to use, parameter semantics, data quirks, and interpretation guidance, and the output schema exists to handle return-value 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?

With 0% schema description coverage, the description carries the entire parameter-documentation burden and succeeds. Every parameter is explained with formats, examples, and semantics: naics is '6-digit, required', set_aside lists valid codes, pricing_type notes the raw-code edge case, value_basis enumerates options, and date_from/to clarify they filter on FPDS action_date.

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 ('Get') and precise resource ('percentile distribution of comparable contract VALUE for a NAICS'), immediately distinguishing itself from siblings like get_price_position and get_labor_rate_benchmark. It also clarifies what it is not ('not a win predictor').

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 explicit context ('Bid & Proposal / Negotiate stage, Pro only') and names complementary tools with their distinct purposes ('Pair with get_price_position to see where YOUR specific value sits, or get_labor_rate_benchmark for the labor-cost input'). The IMPORTANT note tells agents to use pricing-type blocks rather than combined, providing concrete selection guidance.

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

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

The annotations already establish read-only and idempotent behavior, and the description adds meaningful context beyond them: Pro-only access, a maximum sample limit of 25, output chaining via recipient_uei and award_id_piid into profile/contract tools, and the caveat that it is not a bid recommendation. There is no contradiction with the annotations.

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

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

The description is front-loaded with the core outcome, then adds usage context, a parameter bullet list, chaining guidance, and a caveat. Each sentence and bullet adds distinct value, with no filler, and the structure makes the 10-parameter surface manageable.

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 10 parameters with zero schema descriptions, this description is unusually complete: it covers the required fields, the key constraints, the interpretation of results, and downstream tool chaining. The cross-reference to get_price_benchmark for shared filters is acceptable because the sibling is present in the same tool set, and an output schema exists for return-value 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?

With 0% schema description coverage, the description carries the parameter-documentation burden. It clearly defines naics format, value format with examples, and sample_limit semantics and cap. The optional filters are grouped as 'same as get_price_benchmark', which is efficient but not fully self-contained for an agent that may not have that sibling's docstring at hand.

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 opening sentence states a precise operation: compute the percentile rank of a supplied contract/bid value against comparable contracts and return nearest samples. It also explicitly contrasts the tool with get_price_benchmark, making the identity and position in the tool family unmistakable.

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

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

The description names the direct alternative (get_price_benchmark) and explains the distinguishing condition: one places a specific number in the range, the other just returns the market range. It further scopes usage to Bid & Proposal / Negotiate, notes the Pro-only restriction, and clarifies the output is factual positioning, not a recommendation.

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 already cover safety (read-only, idempotent, non-destructive). The description adds context: the 'Award & Compliance tool' classification, a limit cap of 250, and an important behavioral note about reading the 'summary' block first. This adds meaningful operational guidance beyond the annotations.

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 compact and well-structured: main functionality, tool category, key parameter notes, and output summary guidance. No redundant words; important scoping information is front-loaded.

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 detail return values, yet it still mentions the 'summary' block and paginated 'data'. It covers the tool's purpose, direction, key parameters, and output behavior. The only gap is the minimal explanation of optional date/offset parameters, which are inferable but not explicitly documented.

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 zero description coverage, so the description must compensate. It explains 'uei' (the SUB's UEI) and 'limit' (max 250), which is useful, but it omits offset, date_to, and date_from entirely. The description partially mitigates the schema gap but does not fully cover parameter semantics.

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

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

The description uses a specific verb ('Get') and resource ('every prime that has paid THIS company as a subcontractor'), and immediately disambiguates from the sibling tool by naming the opposite direction. This leaves no ambiguity about what the tool does.

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

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

It explicitly contrasts with get_prime_subawards, clarifying the direction and implying when each tool is appropriate. However, it does not provide broader when/when-not guidance beyond that sibling relationship, so it falls short of full usage-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?

Annotations already establish that the tool is read-only, idempotent, open-world, and non-destructive. The description adds meaningful behavioral context beyond that: results are paginated, a summary block should be read before the data rows, and limit is capped at 250.

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 front-loads the core purpose, uses a compact sibling comparison, and uses bullet lines for the parameter notes. Every sentence adds decision-relevant information without padding.

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

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

For a read-only tool with an output schema and only one required parameter, the description covers direction, key parameter constraints, pagination, and the summary block. It gives the agent everything needed to call and interpret the result.

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 descriptions cover 0% of the parameters, so the description carries the burden. It explains uei's format and role and notes limit's max of 250, but it leaves offset, date_from, and date_to undocumented.

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

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

Description states a specific verb and resource: 'Get every subaward THIS company (as a prime) paid out'. It distinguishes itself from the sibling get_prime_relationships by explicitly naming the opposite direction, so an agent can select among related tools.

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

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

It explicitly says this tool is the opposite direction from get_prime_relationships and tells the agent to 'pick based on which direction you're asking'. This is a clear when/alternative rule with no inference required.

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 annotations already declaring readOnly, idempotent, openWorld, and non-destructive, the description adds rich behavioral context beyond the structured metadata: it resolves the WHOLE GAO case across different docket spellings, returns pre-computed booleans, and explains that alternate real spellings produce the same complete set. This goes well beyond the annotations.

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

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

The purpose is front-loaded in the first sentence, the parameter source is a clean bullet, and the return fields are explained in compact prose. Even the longer GAO spelling caveat earns its place by preventing a realistic misreading of duplicate results. Every sentence contributes 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 output schema exists, the description doesn't need to exhaustively document return values, but it still explains the key pre-computed fields, the statutory deadline, the access restriction, and the non-obvious whole-case resolution behavior. An agent has everything needed to call this 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 single parameter has 0% schema description coverage, so the description must compensate. It does add meaningful provenance by telling the agent to take solicitation_number from search_opportunities, search_contracts, or search_protests, but it doesn't give a format, example, or additional constraints. This is adequate but not thorough.

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 and resource: 'Get every protest filed on ONE solicitation,' and immediately clarifies the contestability read for a specific opportunity or award. This clearly distinguishes it from broader sibling search tools like search_protests by emphasizing one solicitation and the statutory decision deadline.

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 clear context for when to use the tool — for a specific opportunity/award — and even tells the agent where to source the solicitation_number from (search_opportunities, search_contracts, or search_protests). It stops short of explicitly saying when not to use it or naming the broader alternative for cross-solicitation protest searches, so it loses the last point.

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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations: it says the tool is 'Factual, signals-not-scores, no win-probability guess' and clarifies that the response's incumbent_uei is the same identifier other tools accept as uei. This is useful but not exhaustive.

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 compact and every line earns its place: core purpose, tool category/access tier, behavioral stance, direct-lookup distinction, piid source, and identifier convention. It is front-loaded with the most important 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?

With an output schema present, annotations covering safety, and one well-sourced parameter, the description is complete enough for an agent to select and invoke correctly. It even covers the sibling distinction and cross-tool identifier semantics, which are the main contextual risks.

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 for piid, so the description must compensate. It does so by telling the agent exactly where to source piid: 'from search_recompetes, get_contract, or get_vehicle'. It also relates the response identifier to the tool family's uei convention, which helps the agent chain calls correctly.

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

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

The description states a specific verb and resource: 'Get one recompeting/expiring contract by PIID, plus incumbent-vulnerability signals'. It differentiates from the sibling search_recompetes by noting this is a direct ID lookup, not a windowed 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?

The description explicitly contrasts this tool with search_recompetes ('Not windowed, a direct ID lookup (unlike search_recompetes)') and tells the agent where to obtain the piid value: 'from search_recompetes, get_contract, or get_vehicle'. It also notes this is a Capture & Teaming / Post-Award tool and Pro only.

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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds minimal extra behavioral context beyond the singular result nature, but it does not contradict annotations and does not need to re-explain what annotations already provide.

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, front-loads the main purpose in the first sentence, and uses a single bullet to fully document the only parameter. There is no filler; the 'Award & Compliance tool' line provides lightweight categorization without bloating the 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?

For a single-parameter, read-only lookup with an output schema and strong annotations, the description is nearly complete. It provides the lookup key source and clearly identifies the resource type. It could go slightly further by stating what happens when no report matches, but that is a minor gap given the tool's simplicity.

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. The bullet explicitly describes subaward_sam_report_id as a UUID and gives concrete provenance ('from search_subawards or a company's subaward list'), adding real meaning beyond the schema's bare string type.

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 action ('Get') and the specific resource ('one FFATA subaward report') and identifies the exact lookup key ('SAM report ID'). It also distinguishes itself from list-like siblings such as search_subawards by explicitly saying 'one' and by framing it as a retrieval-by-ID operation.

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 clear context for when to use the tool: when you already have a subaward_sam_report_id, and it tells the agent where that ID comes from ('from search_subawards or a company's subaward list'). It does not explicitly state exclusions or when not to use this tool, but the usage context is strong enough for an agent to route correctly.

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 annotations already mark the tool read-only and non-destructive, and the description adds valuable behavioral nuances: the vehicle_family block counts sibling PIIDs rather than listing them, rollups are scoped to this PIID only, and the 999999999999 ceiling is FPDS's placeholder for unlimited. This goes well beyond the structured annotations.

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

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

The description is front-loaded with the core purpose and stays tightly organized around the single parameter and the most important return-value caveats. Every sentence adds meaning; the bulleted parameter note and the warnings are directly actionable.

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 one-parameter read-only tool with an output schema and safety annotations, the description covers the essential operational details: input provenance, family-scoping trap, and the ceiling placeholder. Nothing needed to call it correctly is missing.

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 carries the full burden. It clearly defines piid as 'vehicle's own PIID' and instructs the agent where to source it. This is more useful than most schema titles could be.

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

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

The description states a specific verb and resource: 'Get one contract vehicle's detail' and enumerates the returned facets (ceiling, period, what's been ordered). It also distinguishes itself from get_vehicle_holders by explaining the different meaning of vehicle_family data, so an agent can confidently tell them apart.

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 tells the agent where to obtain the required piid parameter ('from search_vehicles or get_contract_vehicle') and explicitly routes to an alternative ('use get_vehicle_holders for the real family-wide count') when a family-wide scope is needed. This is clear when-to-use and when-not-to-use guidance.

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

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses key behavioral traits: it returns separate awardees and earners lists with counts, explains that the counts can be wildly different, and clarifies that vehicle_family.piids rolls up every related PIID so awardee_count reflects the whole family, not just the queried PIID. This is critical behavioral context that annotations do not provide and that an agent must know to interpret results correctly.

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 long but well-structured: it opens with the core distinction, then provides business context, parameter details, and return behavior. Every sentence adds needed information, especially since schema coverage is 0%. It is slightly verbose but not wasteful; a compact but dense layout earns a 4.

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 (two distinct lists, family rollup, Pro-only restriction, parameter sources) and that an output schema exists, the description provides all necessary context for an agent to call it correctly and interpret results. It covers the business rationale, parameter origins, output structure, and the family rollup caveat. Nothing essential is missing.

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 carry the parameter semantics. It explains piid as the 'vehicle's own PIID (from search_vehicles or get_contract_vehicle)' and limit with 'max 250'. While it doesn't fully specify what limit applies to (likely both lists), it gives a concrete bound and source, which is valuable beyond the bare schema. Slight ambiguity about the exact effect of limit prevents a 5.

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

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

The description clearly states the tool's purpose: 'Get who holds a vehicle AND who's actually earning through it' – a specific verb and resource. It distinguishes between two distinct populations (holders vs. earners) and explicitly says not to conflate them. It also ties the purpose to a concrete business question ('can I even compete for this work'), making it unambiguous and distinct from sibling tools like search_vehicles or get_contract_vehicle.

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 provides clear context on when to use it: it's the 'can I even compete for this work' answer on a multi-award vehicle, and only holders can bid task orders. It also mentions the Pro-only restriction and refers to search_vehicles or get_contract_vehicle as sources for the input PIID. However, it does not explicitly list alternatives or state when not to use it, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable operational detail: the list of 7 signals, the `triage` pre-computed summary with its `category`/`label`/`reasons` fields, the semantic meaning of `category: 'clean'`, and the inclusion of `contract_exposure` and `subaward_exposure`. This goes beyond the annotations without contradicting them.

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 longer than some but every sentence carries substance: purpose, use context, parameter guidance, signal breakdown, and exposure fields. It is front-loaded with the core action and deliberately structured with paragraphs and a bullet list, making it scannable. Only minor redundancy (e.g., 'Distinct from check_exclusion' vs. the later explanation) keeps it from a 5.

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

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

With a single parameter, high annotation coverage, and an output schema (has_output_schema=true), the description nonetheless enriches the contract by clarifying the output structure: `triage` as a summary, `signals` list, `contract_exposure`, and `subaward_exposure`. It also teaches the agent how to interpret the result (e.g., clean with empty reasons). Nothing needed to correctly invoke and interpret the tool is missing.

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 carries the full burden of explaining the `uei` parameter. It does this thoroughly: specifies the format ('12-character Unique Entity ID'), lists valid sources (search_companies, search_entities, search_partners, or any other tool's `uei` field), and implies the value is a string. This fully compensates for the missing schema description.

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

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

The description states a specific verb ('Get'), a precise deliverable ('7-signal vendor risk report'), and a target ('one UEI'). It explicitly contrasts with the sibling tool check_exclusion, distinguishing a broader risk read from a binary debarment check, so the agent can easily tell them apart.

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 provides explicit when-to-use context: 'screening facts for teaming or subcontracting due diligence, before you commit to a partner.' It also names the alternative tool (check_exclusion) and explains the distinction, making routing unambiguous.

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 already cover read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds meaningful behavioral detail beyond annotations: the tool accepts both an internal SGS ID and a human-readable WD number, and it reveals that CBA records include a special contractor/union block. This helps the agent understand what the call returns and how the ID can be supplied.

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 compact and front-loaded: the core promise appears in the first sentence, the useful domain context follows, and the parameter detail is a single scannable bullet. No filler or repetition of schema/annotation 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 output schema exists (so return structure is already specified), the description is complete for a one-parameter, read-only tool. It covers what data will be returned, the accepted ID formats, and where a caller can obtain a valid ID, leaving no practical gap 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 coverage is 0%, so the description carries the full burden for documenting wd_id. It does so thoroughly: it explains the parameter accepts either an internal SGS ID or a human-readable WD number, gives realistic examples of both, and states which sibling tools provide valid input values. This is far more useful than the schema's bare string type.

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 the exact operation and resource: 'Get one wage determination's full record' and enumerates the record's components (location array, hourly wage + fringe, CBA contractor/union block). This clearly separates it from sibling search/list tools like search_wage_determinations or get_wds_by_location, which produce collections or location-only results.

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 clear context by labeling the tool as for Bid & Proposal / Negotiate and by explaining that the wd_id comes from search_wage_determinations, get_wds_by_location, or get_wage_rates. It stops short of explicitly stating when not to use related tools like get_wage_rates, but the sequencing guidance is strong enough for an agent to route correctly.

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 already establish readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful behavior beyond those signals: each row is one classification's hourly base wage plus fringe tied to its originating WD, CBAs have no rate table, and state filtering relies on the WD's jurisdictions. This gives an agent a clearer model of what will be 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 front-loaded with the core distinction, then uses a compact bullet list for parameters. Nearly every sentence earns its place by adding scoping or routing information, and the format makes it easy for a model to parse.

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 10 optional parameters, an output schema, and strong annotations, the description supplies enough context for correct tool selection and basic invocation. The main gap is the undocumented offset, sort_order, and active_only parameters, though these are relatively self-explanatory and the output schema likely fills in return-shape 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?

Since schema description coverage is 0%, the description carries the burden, and it largely succeeds: it explains classification (substring, with example), type (DBA | SCA, and notes CBAs have no rate table), occupation_code (SCA 5-digit example), wd_number (exact), state (2-letter via WD jurisdictions), sort_by (allowed values), and limit (max 100). However, offset, sort_order, and active_only are left undocumented, so compensation is not complete.

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 a specific verb ('Query'), a specific resource ('prevailing-wage rates ACROSS wage determinations'), and the dimension of interest ('by occupation'). It explicitly distinguishes itself from search_wage_determinations / get_wds_by_location by contrasting 'what does a given trade actually pay' with 'which WDs apply.'

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 explicit when-to-use guidance by naming sibling tools and pointing to get_wage_rate_summary when the user needs an aggregated distribution/floor across many WDs. It also contextualizes the tool as a Bid & Proposal / Negotiate tool, which helps an agent route intent.

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?

Despite annotations already indicating readOnly, openWorld, idempotent, and non-destructive behavior, the description adds valuable behavioral detail: the response includes distinct_classifications, a broad classification substring can blend multiple differently-paid titles, and DBA CBAs have no rate table. This goes beyond the structured metadata and helps agents interpret results correctly.

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 densely informative and well-structured with clear paragraphs and bullet-like parameter explanations. Though longer than minimal, every sentence adds functional value—no filler—and key directives like preferring occupation_code are front-loaded and reinforce the main caveat.

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, zero schema parameter documentation, and the presence of an output schema, this description is fully sufficient. It covers what the tool does, when to use it, how parameters map to behavior, what distinguishes it from siblings, and an important data interpretation gotcha.

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 carries the full burden. It thoroughly explains every parameter: occupation_code as a 5-digit SCA code with examples and precedence, classification as a name substring fallback, type as SCA vs DBA with the CBA caveat, and state as a 2-letter filter. It also explains the distinct_classifications output behavior.

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 the labor-cost FLOOR for one occupation, aggregated across wage determinations, and details components (base hourly percentiles, H&W fringe, WD count). It distinguishes itself from get_wage_rates as the DISTRIBUTION view versus individual county rate lines, making sibling differentiation explicit.

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 provides explicit usage context: Bid & Proposal / Negotiate tool, the DISTRIBUTION view, distinct from get_wage_rates for individual rates, and paired with get_labor_rate_benchmark for awarded as-bid comparison. It also advises preferring occupation_code over classification when pay spread matters, giving concrete selection guidance.

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

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

With annotations already covering read-only/idempotent safety, the description adds valuable behavior: statewide DBAs are included even when county is specified, there is no date filter, and rows default-sort with CBA first, which can bury DBA/SCA results. No contradiction with annotations.

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

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

The purpose is front-loaded and the parameter bullets make the schema easy to scan. The quoted use case and VA/Fairfax example are helpful but add some length; overall it is structured well and wastes little space.

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 is complete for a current-coverage lookup: it explains scope, type filtering, sort behavior, and limit. The main gap is offset/pagination semantics and a slightly ambiguous county explanation, though the output schema reduces the need to document return shape.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains state, county, type filter values, and limit max of 100. However, offset is not mentioned, and the county note 'omit for statewide only' is somewhat ambiguous despite the earlier clarification about statewide DBAs.

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 identifies the action and resource: returns every currently-active DBA, SCA, and CBA record covering a state/county jurisdiction. It also distinguishes itself from search_wage_determinations by explicitly framing this as a current, not historical, query.

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 explicit usage context ('I'm bidding a contract in this state/county') and names the alternative tool for historical queries, saying 'use search_wage_determinations for that.' This gives an agent clear selection 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?

在注释已表明readOnlyHint=true、idempotentHint=true、destructiveHint=false的基础上，描述额外提供了关键行为信息：cgac代码空间与合同数据不共享、不存在共享标识符、cgac需单独查找不能直接链接；返回organization_id并说明后续如何继续遍历。这些信息远超注释，极大增强透明性。

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?

描述采用分点列表，清晰组织参数信息，关键用法放在开头，结构可扫描性强。虽然长度适中，但每项信息都有实际用途，没有冗余。唯一轻微不足是列表项较多，但整体紧凑。

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?

对于8个参数的列表工具，描述覆盖了核心查询模式、参数语义和后续操作方式，并说明了返回结果如何用于进一步调用。提供输出schema的存在减少了对返回格式的详细描述需求。缺少offset和is_active的说明，但整体功能完整，足以让代理正确调用。

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描述覆盖率为0%，描述承担了参数解释的主要责任。它解释了type、cgac、parent_id、hierarchy_level、search和limit的含义，特别是cgac的警告。但offset和is_active两个参数未在描述中提及，存在轻微遗漏，因此扣一分。

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?

描述明确说明工具用于搜索联邦机构组织树，并给出了具体范围（约907个部门/机构/办公室）。动词'Search'和资源'federal agency organization tree'清晰定义用途，且与兄弟工具如get_organization、lookup_agency等区分开来。

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?

描述明确说明了使用场景：通过'search'解析名称/缩写，或通过'parent_id'列出直接子单位，并指出它属于市场研究工具。还提到与get_organization的衔接方式。虽然没有明确列出'何时不使用'，但已提供足够的上下文来指导选择。

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 already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavior beyond those: results are grouped by canonical name, `suggested_filter_value` may be broader than a single component, and `raw_variations` can be used for narrower filtering. This meaningfully clarifies output semantics, though it does not discuss edge cases such as zero matches.

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

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

The description is front-loaded with the core purpose, then provides usage context, a critical exception, and output-usage nuance. Each sentence adds distinct value, and the structure moves from 'what' to 'when' to 'how to interpret results' without unnecessary filler.

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 lookup tool with read-only annotations and an output schema, the description covers the main gaps: what the query should contain, where the result is meant to be used, where it is not applicable, and how to interpret the suggested filter value. Nothing essential is missing for correct usage.

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 provides no description for the single `query` parameter, but the description fully compensates by specifying accepted forms: acronyms (FEMA, DoD, NASA), partial names, or full agency names. This is exactly the semantic content needed to invoke the tool correctly.

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 and resource: 'Resolve an agency acronym or partial name to canonical SAM.gov agency strings.' It clearly distinguishes the tool from sibling search tools by explaining its role as a name-resolution helper for the `agency` filter rather than a direct data search tool.

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

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

The description explicitly tells when to use this tool: to find the correct `agency` filter substring for search_opportunities, search_companies, and most other tools. It also gives a clear exclusion, noting that search_forecasts uses different natural-language agency names and that this tool's suggestions will not match there.

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?

Beyond the annotations (read-only, idempotent, non-destructive), the description discloses keyset-based pagination, the performance characteristic ('depth doesn't degrade performance'), and the sync-cursor protocol: sync.server_time is returned and should be passed as since on the next call. It also caps the page size, adding real 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?

Every sentence contributes either to usage, parameter rules, or the sync protocol. Bullet points make the parameter semantics scannable, and the instructions are front-loaded with the core purpose before 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 sync loop is fully specified: since, limit, response fields, and the save-and-pass server_time instruction. The only notable gap is the unaddressed offset parameter, which could confuse an agent given the 'keyset-based' claim; a brief clarification on whether offset is supported or unnecessary would make it complete.

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

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

With 0% schema_description_coverage, the description compensates well for since (ISO 8601 format plus concrete example) and limit (max 1000 per page), both absent from the schema. However, offset is left undocumented even though it appears in the schema, so parameter semantics are not fully complete.

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 'List opportunities added or updated since a timestamp', providing a specific verb, resource, and time-scoped filter. This clearly distinguishes it from sibling search tools like search_opportunities, which retrieve arbitrary result sets rather than incremental changes.

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

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

'Use this for incremental sync instead of paginating through search results' explicitly states when to use the tool and what alternative pattern it replaces. The keyset-based note reinforces why this tool is appropriate for deep incremental walks.

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?

Beyond readOnly/idempotent annotations, it discloses that coverage is limited to FFATA subaward filings since FY2025 (~24K firms), that 404 is not a SAM-level negative proof, and that the official SAM translator is admin-gated. This is exactly the behavioral nuance that prevents an agent from drawing the wrong conclusion.

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 dense but well-structured: a one-sentence capability statement, a free-tier note, a parameter line, and a clearly separated coverage caveat. Every sentence adds decision-relevant information without padding.

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

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

For a single-parameter identifier resolver with no nested schema, the description covers input formats, output contents, coverage limitations, and 404 semantics. The presence of an output schema means return-value details need not be repeated in the description.

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 no parameter descriptions, so the description must compensate. It defines accepted formats for DUNS, DUNS+4, and UEI, and states that either side is accepted. This is solid but not exhaustive—case sensitivity and formatting edge cases are not addressed.

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 plus resource: it resolves between legacy DUNS and current UEI, explicitly covering both directions and the returned data. This clearly differentiates it from the broader search/lookup 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?

The description gives clear context for when to call it—any time a DUNS/UEI translation is needed—and adds practical guidance about interpreting 404s in the FFATA-derived crosswalk. It does not explicitly name alternatives or exclusions, but the usage context is strong enough for an agent to select it.

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

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

The description adds substantial behavioral context beyond the annotations: the dataset is sparse, self-reported, contains only ~52K notices, and ~60% of contractors appear with a single notice. This meaningfully elaborates on the openWorldHint and readOnlyHint annotations and prevents the agent from treating results as a complete award history.

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 compact and well-structured: a front-loaded summary, a short use-case contrast, and a bullet list of parameter meanings. Every sentence adds useful information and no content is wasted or redundant.

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

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

The description gives a complete picture of what the tool searches, how it differs from the comprehensive award record, and the semantics of nearly all parameters. The only notable gap is the undocumented offset parameter, which an agent would need for paginated retrieval of large result sets.

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?

Because schema description coverage is 0%, the description compensates by explaining nine of ten parameters: awardee partial match, UEI, 6-digit NAICS, agency substring, USD value bounds, YYYY-MM-DD date bounds, and limit max 1000. However, the offset parameter is not mentioned, leaving pagination behavior undocumented even though the schema only provides its default.

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

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

The description states a specific action and resource: 'Search SAM Award Notices (who won, how much, when).' It also distinguishes itself from search_contracts, making it clear these are SAM notices rather than the comprehensive federal award record, so an agent can tell this tool apart from closely related 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?

The description gives explicit when-to-use guidance: use search_contracts for the comprehensive authoritative award record, and use this tool specifically when the question is about a SAM-noticed award rather than the company's overall federal business. It also warns about the sparse self-reported nature of the data, which helps an agent choose correctly.

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 already indicate a safe, read-only, idempotent operation. The description adds beyond that: case-insensitive substring match, minimum 2-character query, award-based inclusion, Pro-only restriction, and the key distinction between SAM-only totals and FPDS activity. No contradiction with annotations exists.

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

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

The description is dense but every sentence earns its place. Scope and sibling routing are front-loaded, followed by tight parameter bullets and return-value semantics, with no filler or repetition of schema fields.

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 covers scope, eligibility, parameter semantics, Pro gating, the shared uei identifier, and the meaning of the returned totals, so an agent can mostly invoke it correctly. The only meaningful gap is explicit offset/pagination behavior, which keeps it from being fully self-contained.

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, the description compensates well by explaining q, naics, agency, naics_small, and limit with formats, examples, and behavioral constraints. However, offset is never mentioned, and the assertion that q is 'REQUIRED' conflicts with the schema's zero required parameters and null default, leaving a minor reliability 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 opening sentence states a specific verb ('Search'), an exact scope ('companies that have WON at least one federal award'), and the two data sources (SAM Award Notices and FPDS prime contracts). It also immediately contrasts this with search_entities, making the tool's purpose unambiguous among many 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?

The description explicitly routes the agent to search_entities for all registered SAM firms and to get_company_profile for direct UEI lookups. It also warns that q is required and that naics/agency/naics_small only narrow an existing name search, preventing invalid standalone 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?

Beyond the readOnlyHint/idempotentHint/destructiveHint annotations, the description discloses important behavioral details: Pro-only access via contacts_access, two input modes with different matching semantics (substring vs exact), result limits (up to 5 vs one), and specific error outcomes (404 and 402). This gives an agent a strong model of runtime 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 well-structured and front-loaded: purpose first, then access constraint, then usage modes, then error behavior. Every sentence adds operational value and none merely restates the tool name or schema.

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

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

Despite having no required parameters and only sparse schema titles, the description fully covers what an agent needs: what to provide, which mode to choose, what results to expect, and what errors to anticipate. The presence of an output schema covers return shape, so the description does not need to restate it.

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 carries the burden of explaining parameters, and it does: name is a substring match, email is exact, and state/agency are optional for disambiguation. It lacks format details for state/agency values, but the core semantics of all four parameters are meaningfully explained.

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

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

The description uses a specific verb ('Look up') with an exact resource: CONTRACTING OFFICER contact info, and immediately distinguishes itself from get_company_contact on the vendor/teammate side. Calling it a 'RESOLVER, not a directory' further sharpens what the tool does and does not do.

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 states exactly when to use the tool (resolving a specific contracting officer), explicitly names the sibling alternative it is not (get_company_contact), and gives mode-selection guidance: name vs email with optional disambiguating parameters. It also warns that this tool cannot list or browse contacts, preventing misuse.

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?

Beyond the readOnly and idempotent hints, the description reveals the non-obvious FY2025 coverage floor and that an early date_from is silently clamped rather than rejected, with a window block disclosing what actually ran. It also calls out the behavioral difference from search_vehicles regarding flooring.

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 long, but every paragraph serves a distinct purpose: scope and alternatives, parameter semantics, data coverage caveat, and result chaining. The material is front-loaded with the core purpose before moving to structured 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 15 optional parameters and an output schema, the description covers what an agent needs to call it correctly: source scope, parameter formats and constraints, the clamping behavior, defaults, max limit, and downstream tool routing. The output schema can handle return-field details, so no critical context is missing.

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?

Because schema description coverage is 0%, the bulleted parameter notes carry the full burden and do it well: exact 12-char UEIs, 6-digit NAICS, YYYY-MM-DD date format, FPDS award type codes, allowed sort fields, and a limit cap of 250. The offset parameter is not described, so a small but real gap remains.

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 and resource: Search FPDS prime contract transactions, and characterizes it as the comprehensive authoritative award record. It immediately distinguishes itself from the sparse SAM Award Notice slice in search_awards, so an agent can separate it from close sibling tools.

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

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

It explicitly routes SAM Award Notice queries to search_awards and contrasts its coverage-floor behavior with search_vehicles, which is not floored. It also tells the agent what to do with results by chaining award_id_piid to get_contract, get_contract_modifications, and get_contract_vehicle.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description appropriately goes beyond those to add plan restrictions (q vs. Pro filters), error behavior for business_type (400 with valid list), and the fact that it returns uei which is consumed by other tools. This adds useful context, though it doesn't address pagination or rate limits explicitly.

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 longer than average but well-structured: it opens with purpose and alternative, then lists parameters in a clean bullet style. Every line earns its place, though the 'Capture & Teaming tool' note could be considered extraneous. It is organized and front-loaded.

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 an output schema exists, the description doesn't need to explain return structure, but it still ties the result to the shared uei identifier, discusses plan limitations, and provides error handling details. This makes it complete for an agent to call correctly, covering parameters, constraints, and integration with other 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?

With schema description coverage at 0%, the description compensates well by explaining q, naics, state, business_type (with examples like '8W'), active_only, naics_small, and limit (max 100). However, it omits the 'offset' parameter entirely, leaving a gap in pagination understanding. Otherwise it adds strong 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 explicitly states the tool 'Search ALL SAM-registered entities by name' and immediately differentiates it from the sibling search_companies by noting that search_companies has richer award-history fields. This makes the purpose unambiguous and distinguishes it from closely related tools without needing to open schemas.

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?

Directly instructs when to use this tool vs. an alternative: 'For companies that have actually WON an award, use search_companies instead... use this one when you need the full registry'. It also clarifies that only 'q' works on every plan and other filters are Pro, giving clear usage 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, but the description adds significant behavioral context: the forward-looking nature, pre-solicitation meaning, recompete signal relationships, and Pro-gating of contact fields. No contradiction with annotations and substantial extra transparency.

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