PubSec Radar

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

With no annotations provided, the description fully bears the transparency burden. It discloses data source (daily USAspending snapshot), coverage (current FY plus 3-year trend), freshness (stated in response), and limitations (partial-year, intel-agency never published). No contradictions or omissions.

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

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

The description is a compact paragraph of about 5 sentences, beginning with a clear purpose statement. Every sentence adds essential detail: outputs, example usage, data source, freshness, and caveats. No redundant or vague language.

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 tool with one required parameter and no output schema, the description fully equips an agent to decide when to call it and what to expect. It covers purpose, typical usage, data source, limitations, and output components. No additional context is needed 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?

The single parameter 'agency' is fully described in the schema with examples. The description adds contextual value: 'Good queries name one agency' and 'before a first call,' which aids interpretation. While the schema coverage is 100%, the description provides minimal but useful extra guidance.

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's purpose: answering 'what does this agency actually buy, and from whom?' and lists specific outputs (total obligations, 3-year trend, top vendors/NAICS). It clearly distinguishes from sibling tools like 'find_expiring_contracts' which focus on other aspects, and positions it as a pre-call profiling 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 provides clear usage guidance: use before a first call, good queries name one agency (e.g., 'HHS'), and includes caveats (federal only, partial-year data, intel-agency exclusions). It lacks explicit 'when not to use' or direct alternatives among siblings, but the context is sufficiently 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?

No annotations provided, so the description carries the full burden. It discloses the tool's focus on federal contracts, the meaning of expiring contracts (upcoming recompetes), and that responses include data-freshness and coverage caveats. This adds value beyond the schema, though it does not elaborate on authorization or rate limits.

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

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

The description is a single concise paragraph that front-loads the purpose, then gives usage guidance and an example. No word is wasted; every sentence serves a distinct informative purpose.

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

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

No output schema exists, so the description must cover return fields. It mentions incumbent vendor, dollar values, contracting office, and data-freshness caveats. This is sufficient for a tool of moderate complexity, though it could include pagination or sort order details.

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

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

Schema description coverage is 100%, so baseline is 3. The description enhances schema info with a concrete example (agency='DHS', naics_code='541512', window_days=90) and explains the 'limit' parameter sorts by obligated amount. This adds practical clarity for parameter usage.

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 finds expiring federal contracts for sales triggers, specifying the return fields (incumbent vendor, dollar values, contracting office). This distinguishes it from siblings like agency_spend_profile or incumbent_lookup, which have different purposes.

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 says 'Use this when prospecting or prepping a federal account and you want sales triggers' and provides example queries. It also notes 'Federal only (no state/local)'. However, it does not explicitly state when not to use or provide alternatives, though the context 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?

No annotations provided, so description carries full burden. It discloses that questions are data-backed with URL sources, tuned to public-sector specifics (fiscal-year timing, contract vehicles, FedRAMP/ATO, incumbents). Does not mention auth or rate limits, but is transparent about core 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?

Two sentences, no wasted words, includes example and context. Front-loaded with key usage guidance, then details. Highly efficient.

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?

No output schema, but description explains return format (discovery questions with data-backed citations). Covers all 4 parameters, usage context, and public-sector nuances. For a tool of this complexity, it is quite complete, though could mention if multiple questions are returned.

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 100%, so baseline is 3. Description adds value by providing a concrete usage example and explaining the role of naics_code for expiring-contract questions. Explains all four parameters purposefully beyond schema.

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

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

The description clearly states it generates discovery questions for public-sector selling, with specific verb 'returns discovery questions' and resource. It distinguishes from sibling tools like agency_spend_profile by focusing on question generation rather than data retrieval.

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

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

Explicitly states 'Use this when prepping a meeting with a federal agency' and provides an example query. Lacks explicit 'when not to use', but context implies not for non-public sector. Good guidance on optional parameters like naics_code.

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

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

Without annotations, the description fully discloses behavior: returns current/recent awards with values and end dates, flags those ending within 12 months, notes federal-only scope, and addresses name-matching caveats with zero results.

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

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

Three sentences front-load the purpose, provide usage guidance, and address edge cases, with no wasted words.

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

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

Despite no output schema, the description fully explains return values (awards with values, end dates, displacement flags) and handles caveats, making the tool self-contained for an agent.

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

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

With 100% schema coverage, the description adds substantial meaning beyond the schema by providing example queries, explaining name matching, and illustrating expected input patterns like vendor='Booz Allen', agency='DHS'.

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 specific verb 'Look up' and resource 'incumbent vendor's federal contracts', and clearly distinguishes from siblings by focusing on displacement windows and answering 'who am I displacing and when?'

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 states when to use ('to answer who am I displacing and when?') and provides query examples with vendor and agency, but does not explicitly mention when not to use or compare with sibling tools.

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

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

Without annotations, the description carries the burden. It discloses that scores measure 'evidence specificity, not truth', and that public-record evidence for incumbent_vendor is automatically attached. It also mentions the output includes gap-closing questions. However, it does not mention error handling, rate limits, or behavior when required fields are missing beyond schema validation.

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

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

The description is a single dense paragraph that packs a lot of information. While it is front-loaded with the core purpose, it could be broken into shorter sentences or bullet points for easier parsing. Some phrases are verbose (e.g., 'public-record evidence pulled automatically').

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 there is no output schema, the description adequately explains the return format: an evidence-scored scorecard with gap-closing questions and public-record evidence. It also explains the scoring philosophy. However, it does not specify the structure of the scorecard or how results are presented.

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

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

Schema coverage is 100% and each parameter has a description, but the tool description adds meaningful context beyond the schema. For example, it explains that 'economic_buyer' is 'who has budget/obligation authority' adapting to public sector. The nested 'deal_facts' object is explained in terms of MEDDPICC dimensions.

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: 'pressure-test a federal deal' using MEDDPICC dimensions. It distinguishes itself from sibling tools by specifying the federal/public-sector adaptation and the output format (scorecard with gap-closing questions). No other sibling appears to do the same specialized scoring.

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

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

The description explains when to use: 'pass what you know per MEDDPICC dimension (leave unknowns empty) and get back an evidence-scored scorecard'. It implies that this is for qualification, not discovery, but does not explicitly state when to use alternatives like 'generate_discovery_questions' or 'incumbent_lookup'. The context is clear, but explicit exclusions are missing.

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