search_gov_and_sec_triggers

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

No annotations are provided, so the description carries the full burden. 'Search' and 'live' imply a read-only, real-time query, and it usefully discloses the output shape (0-100 deterministic score plus outreach briefs). However, it says nothing about rate limits, pagination, per-source auth requirements, or the free-vs-PRO behavior that the proApiKey and maxResults params imply.

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?

A single front-loaded sentence that packs sources, scoring, and output type with no filler. It is dense but every clause earns its place; only minor loss for cramming three ideas into one sentence without structural separation.

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 seven parameters, no annotations, and no output schema, the description does cover the essentials: what is searched, where the data comes from, and what comes back. It omits the tiered-access model (free cap of 5 results vs PRO enrichment) and any latency or reliability expectations, leaving meaningful gaps for a tool this complex.

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 every parameter including the source enum and defaults is already documented. The description adds no syntax, format, or interaction detail (e.g. how keywords combine with query, or how minAmount applies across sources) beyond what the schema states, so the baseline of 3 applies.

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 (Search) and concrete resources (federal contracts, grants, SEC 8-K filings), naming the underlying sources USAspending.gov and Grants.gov. It is clearly distinguishable from siblings like scan_ats_hiring_pain_signals or generate_3step_cold_sequence, though it never explicitly contrasts itself with them.

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

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

Usage context is only implied: 'B2B buying-intent scoring' and 'cold outreach briefs' signal a sales-prospecting scenario. There is no explicit when-to-use guidance, no mention of when not to use it, and no routing to any of the seven sibling tools despite obvious overlap with ATS pain-signal scanning and sequence generation.

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