FundingLandscape

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description's 'Search' verb is consistent with them. The description adds genuinely useful behavioral context beyond annotations: quota accounting ('Counts toward your monthly searches. A batch counts as 1 call'), response size behavior (~4KB for 10 results), and the guarantee that behavior is unchanged from the deprecation. Minor omissions like rate limits or error behavior prevent a 5.

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?

Five short sentences, each earning its place: deprecation routing first, then purpose, default size, control knobs, pagination hint, and billing implication. No fluff or repeated schema content. Front-loading the deprecation warning is exactly what an agent needs before deciding whether to call this tool.

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 12-parameter tool with nested objects and no output schema, the description covers the essential operational facts: purpose, default response size, size control, total-count pagination signal, deprecation status, and quota cost. The return-value picture is partially left to the schema (e.g. newSince summaries), but the description fills the most critical gaps an agent faces. Not exhaustive enough for a 5given no output schema and 12 parameters.

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 92%, so the schema already documents nearly all parameters in detail. The description adds a small amount of cross-parameter guidance—that detail_level and max_results jointly control response size, and the ~4KB default scaling—but does not substantially go beyond the schema's already rich parameter descriptions. Baseline 3 is appropriate given the high schema coverage.

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 ('Search grants, prizes, and foundations comprehensively') and immediately establishes its role as a deprecated alias of search_grantsplus, distinguishing it from the preferred sibling. An agent can tell exactly what it does and how it relates to its siblings without inspecting the 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?

The first sentence explicitly routes agents to the preferred alternative ('prefer search_grantsplus with a queries[] array, which now runs the identical batch fan-out') and states this tool exists only for backward compatibility. It also gives concrete control guidance: 'Use detail_level and max_results to control response size' and explains the pagination cue ('Response includes total available count so you can request more if needed').

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 mark the tool as read-only, idempotent, and non-destructive, so the bar is lower, but the description still adds substantial behavioral context: default response size ~4KB, total available count included, placeOfPerformance aggregation semantics, monthly-search quota impact, and that a batch counts as one call. It even discloses subtle interaction behavior with user_context.location_strict. This goes well beyond what annotations 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 front-loaded with the most important decision-relevant fact (deprecated alias, use search_procurement), followed by the core function and response-size guidance. It is dense but every sentence earns its place; nothing is filler or redundant with 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 complex tool with 11 parameters and no output schema, the description provides the essentials: deprecation status, replacement route, default result count, size-control levers, total-count behavior, aggregation semantics, and quota impact. Combined with the detailed input schema, there is enough information for an agent to invoke this tool correctly and interpret the response.

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?

Input schema coverage is 91% with rich per-parameter descriptions, so the baseline is 3. The description adds meaningful parameter strategy: it calls out using detail_level and max_results to manage response size, notes the default 10-result response, and highlights that total available count lets the agent request more. It does not repeat the full schema, which is appropriate given the high schema coverage.

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 clear 'DEPRECATED ALIAS' label and names the preferred replacement, search_procurement, while still stating the actual function: 'Search federal contracts (SAM.gov) comprehensively.' This lets an agent distinguish it from search_procurement and understand it is a backward-compatibility shim. The verb and resource are specific and 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 explicitly says to prefer search_procurement with a queries[] array and explains that this tool is kept only for backward compatibility. It also gives practical guidance on controlling response size with detail_level and max_results, which helps the agent make appropriate choices. No guessing is required about when to choose this tool or its sibling.

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/idempotent/non-destructive, but the description adds traits they cannot express: it returns immediately, performs no database calls, and does not consume the monthly search quota. It also discloses the important failure-mode distinction that auth errors surface separately.

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?

Four short sentences, front-loaded with the action and the trigger, then the limits and the quota note. Every sentence carries distinct information with no 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?

For a zero-parameter diagnostic with no output schema, the description fully covers what a call does, what a success means, what it does not mean, and its cost profile. Nothing an agent needs before calling it 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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond confirming the call is parameter-free.

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 and resource ('Verify MCP server connectivity') and immediately bounds the scope with 'no database calls'. It is clearly distinguishable from sibling auth/status tools such as get_account_status.

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

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

Gives an explicit trigger ('Use this FIRST if experiencing tool errors') and explicitly rules out what a success does NOT prove (account, search, paid-feature auth). The boundary condition that routes to the auth path is spelled out rather than inferred.

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 only cover safety (readOnly/idempotent/non-destructive), and the description layers on substantial behavioral context: a bounded page of ~50 candidates per section, exclusion of non-biddable and past/undated rows, counts that are not exact eligible totals, authenticated free/paid requirement, and that the call counts toward a monthly search allowance.

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

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

Purpose is front-loaded in the first sentence and subsequent sentences each carry a distinct constraint. It is dense and somewhat run-on in the middle (compact/coverage/counts), with mild restatement of the compact flag already in the schema, but little is truly 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?

There is no output schema and no annotations covering returns, so the description must carry that load and it does: it describes the results shape, section counts and index ranges, the coverage continuations, exclusion rules, and pagination bounds. An agent has enough to call and interpret 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 coverage is 100%, so the baseline is 3. The description still adds value: it explains the compact-vs-full payload tradeoff in terms of merged `results` rows and section arrays, and clarifies that omitting `category` yields separate grants and procurement sections rather than a single 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+resource (get upcoming funding deadlines) and scopes it to planning an application schedule. It also distinguishes the default balanced grants+procurement view from the single-category mode. It does not name any sibling search tool to route the agent, so it stops short of full differentiation.

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?

Gives concrete guidance on when to pass compact:false and when to pass category, which is genuinely useful. However, with many lookalike siblings (search_grantsplus, search_procurement, batch_search_*), it never says when to prefer this calendar over a search tool. Usage is implied rather than contrasted.

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 mark destructiveHint=true and idempotentHint=true. The description adds a non-obvious side effect—'Does not count toward your monthly searches'—which is not captured in annotations. This extra detail helps an agent understand the impact beyond the basic safety profile.

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 consists of three short, purposeful sentences: the action, the prerequisite, and a relevant side-effect. No redundant or filler content is present, making it highly concise and well-structured.

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 delete tool with one parameter, no output schema, and strong annotations, the description covers the necessary steps (how to get the ID, the action, and a side-effect). It is sufficiently complete, though it could optionally mention that deletion is permanent, but that is already implied by destructiveHint.

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 100% description coverage for the single 'id' parameter, explaining it comes from list_saved_searches. The description repeats this same guidance without adding new semantics, so it provides no additional meaning beyond the schema.

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

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

The description clearly states the action ('Delete a saved search by ID') with a specific verb and resource, distinguishing it from sibling tools like list_saved_searches, save_search, and update_saved_search. It also specifies the scope (by ID) and directs the user to list_saved_searches first, reinforcing the intended purpose.

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 an explicit prerequisite: 'Use list_saved_searches first to find the ID.' This gives clear workflow guidance. While it doesn't mention alternatives, no other delete tool exists among siblings, so the guidance is sufficient for correct 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?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: output structure (confidence tiers, ranked funders, amounts, grant counts, filing years), the historical-evidence limitation, and the quota note that it does not count toward monthly searches. 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?

Four sentences with no filler; the core purpose is front-loaded and each subsequent sentence adds a distinct piece of useful information (output details, exclusions, quota impact). Dense but efficient, with the only minor issue being one long sentence that packs many return details together.

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 no output schema, the description does a good job explaining what results look like and what the data does and does not represent. It covers data source, confidence tiers, ranking, filing years, exclusions, and quota. It does not explicitly walk through pagination or state filtering, but those are documented in the schema, so the description is sufficiently complete for 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 100%, so the baseline is 3. The description reinforces the organization-name matching idea but does not materially add detail beyond what the schema already documents for page, limit, state, or organization. It earns the baseline rather than exceeding 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?

States a specific verb ('Find') and a precise object: private foundations whose covered 990-PF filings name a given organization as a grant recipient. This clearly distinguishes the tool from siblings like search_foundations or funders_for_cause by describing the exact data source and relationship being searched.

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 an explicit use case: researching who funds peer organizations doing work like the user's. It also includes important exclusions ('NOT an open call, a current interest statement, or an eligibility signal'), though it does not name specific alternative sibling tools or conditions for choosing them.

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 the safety profile (readOnly, idempotent, not destructive), and the description adds substantial context beyond them: returned fields (similarityScore 0-1, matchExplanation), the signals used for matching, auth requirements, and that calls consume the monthly search allowance with free-plan listing limits still applying. This quota/auth disclosure is exactly the kind of behavioral context annotations cannot convey.

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?

Front-loaded with purpose and mechanism, and each sentence is informative. However, the three trailing sentences about account access and quota ('Available to authenticated free and paid accounts... Free-plan listing-access limits still apply. Counts toward your monthly searches.') overlap and could be condensed into one.

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 no output schema, the description steps in to describe return values (similarityScore and matchExplanation). Combined with the annotations covering safety, and the auth/quota disclosure, an agent has everything needed to invoke this correctly.

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

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

Schema description coverage is 100%, so both parameters (opportunity_id and limit) are already documented in the schema, including defaults and max. The description implies opportunity_id semantically ('similar to a given one') but adds no format or constraint detail beyond the schema. Baseline 3 is appropriate when the schema carries the parameter burden.

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 (find), resource (opportunities), and the mechanism (semantic similarity/vector embeddings). It explicitly distinguishes itself from keyword-based siblings like search_grantsplus by noting it finds 'conceptually related opportunities, not just keyword matches.' An agent can tell exactly what this does versus the sibling search 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?

Gives a clear trigger condition: 'Useful when user likes one result and wants more like it,' which maps cleanly to the required opportunity_id input. It does not name an explicit alternative tool or state when NOT to use it (e.g., versus get_opportunity), so it stops short of full when/when-not 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?

Annotations already mark the tool read-only and idempotent, and the description adds meaningful behavioral context: the cause is the NTEE group of the recipient, the results reflect actual giving history, and searches do not count toward monthly search limits. This goes well beyond the structured hints by explaining what the data represents.

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 adds necessary nuances about data source and recipient attribution. The long cause list is functional since no enum is provided in the schema, and the note about monthly search counts is a relevant operational detail. Every part serves a clear 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?

With four parameters, detailed cause enumeration, and clarifying notes on state semantics and search quotas, the description is largely complete. It does not explicitly describe the shape of the returned funder list, but the purpose sentence makes the result set obvious enough for an agent to invoke and interpret the result. Minor gap only.

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?

Although the schema already describes all four parameters, the description enriches them significantly: it lists every valid cause name with its NTEE letter, explains that state applies to the recipient rather than the funder, and gives a concrete example like 'Education' or 'B'. This reduces ambiguity that the schema alone would leave open.

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 the private foundations that have given to recipients in a cause area," immediately distinguishing this from generic funder search tools. It further clarifies that it reports actual giving by recipients based on IRS NTEE major groups, not what a funder says it funds, which uniquely positions it among 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 clearly states what the tool is for—finding funders by cause area optionally limited to a state—and adds context such as "Historical filing evidence, not an open call." It does not explicitly name alternative sibling tools or say when not to use them, but the intended use case is strongly implied and actionable.

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 mark readOnlyHint=true and idempotentHint=true. The description adds valuable context with 'Does not count toward your monthly searches,' a non-obvious behavioral trait that is not inferable from annotations alone.

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, fully front-loaded with the purpose, and every clause adds value. Extremely 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?

Given the tool's simplicity (no parameters, no output schema, clear read-only behavior), the description covers all necessary context. It explains what the tool returns conceptually and its non-consuming nature.

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?

There are zero parameters, so the description has no parameter details to add. Per the rubric, a baseline of 4 is appropriate for zero-parameter tools.

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 ('check') and clearly identifies the resource ('subscription status, usage this period, and remaining searches'). It distinguishes from sibling search tools by focusing on account-level information.

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?

States 'Use anytime to see how many searches you have left,' providing clear context for when to call. Does not explicitly exclude alternatives, but the guidance is unambiguous enough given the sibling list.

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. The description adds that the operation does not consume monthly search quota and returns category names with counts, which is additional 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?

Two sentences, front-loaded with the action, then examples and a usage note. Every sentence earns its place 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?

For a zero-parameter tool, the description sufficiently explains what it does, what it returns, and the value of using it. The lack of an output schema is compensated by the mention of category names and opportunity counts.

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

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

The tool has zero parameters, so schema coverage is trivially complete. The description adds context about the returned categories and counts, which enriches understanding without needing to discuss parameter syntax.

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 'Browse all funding categories with opportunity counts', which is a specific verb+resource combination. It clearly distinguishes itself from sibling search tools by focusing on category listing rather than searching for specific opportunities.

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 states 'Useful for understanding what types of opportunities are available', providing clear context for when to use it. It also notes 'Does not count toward your monthly searches', giving a practical benefit. However, it does not explicitly mention when not to use it or alternatives.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a valuable behavioral trait: this operation does not consume monthly search quota, which is not present in the annotations. This goes beyond what structured data provides.

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 two sentences, both earning their place. The first sentence front-loads the main purpose with specific details, and the second delivers a useful operational note. No fluff or 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?

For a zero-parameter, read-only tool, the description is largely complete. It specifies what the summary contains and notes the quota behavior. The lack of an output schema could have been mitigated with a brief hint about the return structure, 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?

This tool has zero parameters, so per the rubric baseline for 0 params is 4. There are no parameter semantics to clarify, and the description correctly omits any parameter-related content since none exist.

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 returns dataset size and coverage statistics (open opportunities, certified sources), going beyond a generic restatement. It distinguishes this tool from sibling tools like get_categories or search_grantsplus by focusing on summary metrics rather than detailed records.

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?

Although it doesn't explicitly mention alternative tools, the description implies when to use it—when an overview of dataset size and coverage is needed. The added note that it does not count toward monthly searches provides useful context for choosing this tool freely, but there are no explicit exclusions or alternative names.

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 discloses important behavior: the returned description is capped at 12,000 characters, descriptionCoverage reports truncation and returned length, and without an mcp-session-id a compact description is returned instead. It also notes the call does not count toward monthly searches, adding useful context about side effects and 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 main function is front-loaded in the first sentence, and subsequent sentences cover genuinely needed edge cases such as truncation and sessionless behavior. It is somewhat dense around the sessionless workflow, but every sentence contributes necessary usage or behavioral 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 no output schema, the description compensates by explaining what the response contains (description text, descriptionCoverage), how to detect truncation, how to retrieve the full text, and the ID requirement. Nothing an agent needs in order to invoke this tool correctly 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 description coverage is 100% and the schema already specifies that id must be the exact opportunity ID from search results in CUID format. The description repeats and emphasizes this instruction, but does not add materially new parameter semantics beyond what the schema already provides.

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 begins with a specific verb and resource: 'Get details for a specific funding opportunity.' It clearly distinguishes this from sibling search/list tools by framing it as the targeted per-opportunity detail lookup, and it is not easily confused with get_foundation or other 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?

The description gives clear usage context: use the exact id from search results, do not construct or guess IDs, and handle truncation by consulting the source URL or echoing the header for the full text. It does not explicitly name alternative tools or exclusion criteria, but the one-parameter prerequisite is stated strongly.

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 readOnlyHint=false and openWorldHint=true, signaling a non-read operation with external effects. The description adds valuable behavioral context: 'Requires active subscription' and 'Does not count toward your monthly searches', which go beyond annotation defaults and clarify the transactional nature.

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 extremely concise: two sentences with no filler. It front-loads the core action ('Buy Search Pack') and adds necessary constraints and benefits in an efficient manner.

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 one-parameter tool with good annotations and complete schema, the description is largely sufficient. It would benefit from stating that the tool returns a payment link (as implied by the name), but the lack of an output schema makes this a minor gap. Overall, it is complete for intended use.

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 covers the 'quantity' parameter fully with a description and default. The tool description adds product details like price and expiration but does not add meaning to the parameter itself. Since schema description coverage is 100%, a score of 3 is appropriate.

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: 'Buy Search Pack', with specific details like price ($5), quantity (50 searches), and conditions (requires active subscription). It is specific and distinguishes itself from sibling tools like get_upgrade_link by focusing on purchasing a pack rather than upgrading a subscription.

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 for when to use this tool: when you have an active subscription and need additional searches. It also notes that it 'does not count toward your monthly searches', implying a quota-related use case. However, it does not explicitly name alternatives or state when not to use it, so it falls 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 establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond annotations: it explicitly states that usage does not count toward monthly searches, which is a quota-impact trait not present in structured metadata. It also clarifies return content. This exceeds the minimum, but lacks details on errors or response format.

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 two concise sentences, front-loaded with the primary purpose. Every sentence adds value: the first states the action and the second explains the output and a key behavioral caveat. 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?

For a zero-parameter, read-only tool, the description is fully complete. It tells the user what the tool does, what it returns, and a relevant quota behavior. The annotations cover safety, and no output schema is needed. Sibling tools are not similar enough to require further disambiguation.

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

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

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and the schema is trivially complete. No additional parameter semantics are required.

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

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

The description clearly states the tool's purpose: 'Get pricing for all plans.' It specifies the verb and resource, and also outlines what is returned ('names, prices, features, limits'), making it distinct from sibling tools like get_pack_link or get_upgrade_link. The inclusion of 'all plans' provides additional scope.

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

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

The description implies use when pricing information is needed, and the note 'Does not count toward your monthly searches' gives context about when to use it relative to quota. However, it does not explicitly name alternatives or state when not to use it, which prevents 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 read-only, idempotent, and non-destructive behavior. The description adds value by disclosing the quota exemption ('Does not count toward your monthly searches') and the client scope. This goes beyond what annotations provide, though it doesn't describe return format or pagination, which are not critical for a zero-parameter 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 exactly two sentences, with the core purpose in the first sentence and a key behavioral note in the second. Every word earns its place, and it is front-loaded with the action.

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 zero-parameter, read-only tool with good annotation coverage and no output schema, the description fully covers the essential aspects: what it returns, for whom, and a relevant non-functional characteristic. No additional context is necessary.

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

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

The tool has zero parameters, so the input schema is empty and fully described. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter information. It correctly avoids inventing parameters.

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 ('Return') and resource ('MCP setup instructions for Claude Desktop and other clients'), clearly stating what the tool does. It is distinct from sibling tools, as no other tool provides setup instructions.

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

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

The description implies usage when setup instructions are needed and highlights that the tool does not count toward monthly searches, which is relevant context for choosing it. However, it does not explicitly mention when not to use it or compare with alternatives like get_tool_guide.

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 and idempotentHint, so safety is covered. The description adds valuable behavioral context beyond annotations: it clarifies the tool returns documentation ('Returns detailed documentation...') and discloses that it does not consume monthly search quota. This is useful cost/behavioral information not present in 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?

Three concise sentences, each with a distinct purpose: stating the tool's function, providing usage order, and disclosing cost/scope. No filler or redundant repetition of schema/annotations. The description is front-loaded with the core purpose and stays tight.

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 tool with one optional parameter, strong annotations, and no output schema, the description covers all necessary aspects: what it does, when to call it, what it returns, and its cost profile. The absence of output schema is acceptable because documentation output is inherently freeform and the description already states it returns 'detailed documentation.'

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% with a clear description of the 'topic' parameter and its enum values. The description incidentally mentions content areas ('search tools, filters, and token optimization strategies') that map to topics, but it does not add meaningful syntax or usage details beyond the schema. Baseline 3 is appropriate since the schema handles parameter documentation.

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

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

The description begins with 'Get comprehensive usage guide for FundingLandscape tools,' clearly stating the action (get guide) and resource (FundingLandscape tools). It also distinguishes itself from sibling search tools by explicitly positioning it as a first-call meta tool: 'Call this FIRST.'

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 the tool: 'Call this FIRST to understand optimal workflows, parameter usage, and best practices.' It also provides a cost-related guideline: 'Does not count toward your monthly searches,' which helps the agent decide to use it freely. Though no alternatives are named, the tool's unique role as a guide makes the advice 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?

The description discloses important behavioral details beyond the annotations: authentication requirements, the sign-in instruction return if unauthenticated, the need to call again after sign-in, and that it does not count toward monthly searches. This adds significant context that the annotations do not 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 short, front-loaded with the primary purpose, and every sentence adds value. Important warnings are highlighted, and there is no redundant or filler content.

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 tool with two optional enum parameters and no output schema, the description covers all essential aspects: what it returns, authentication requirements, the re-call instruction, and whether it affects usage limits. No critical information 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 already provides 100% coverage of the two parameters, including enums and default descriptions. The tool description does not add any additional meaning to the parameters beyond what the schema already states, so the baseline score of 3 is appropriate.

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 Stripe checkout URL for subscription.' It uses a specific verb and resource, distinguishing it from sibling tools like get_pack_link and get_pricing. However, it does not explicitly differentiate itself from those siblings by name, which prevents a perfect score.

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 context, including the prerequisite to sign in first, what happens if not authenticated, and the need to call again after OAuth sign-in. It lacks explicit 'when not to use' guidance or named alternatives, but the context is sufficient for an agent to know when to invoke this tool.

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 and idempotentHint=true, so the safety profile is established. The description adds substantial behavioral context: return fields, plan-specific limits, remaining slots, and the fact that it doesn't count against monthly search quotas. 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 concise and front-loaded with the core action ('List all saved searches'). Every sentence adds value: return fields, usage priority, plan details, and monthly search note. No redundant or vague phrasing.

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 zero-parameter read-only tool with no output schema, the description is complete. It covers what the tool returns, why it should be used first, plan availability, and operational impact. The context signals confirm low complexity, and the description fills all gaps.

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

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

The tool has zero parameters, so the schema is complete by definition. The baseline of 4 for no-parameter tools applies; the description appropriately focuses on response content rather than parameters, which is not needed.

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 'List all saved searches for the current user' with a specific verb and resource, clearly distinguishing it from sibling tools like save_search and update_saved_search. It also enumerates the returned fields, which adds specificity.

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 instruction 'Use this FIRST to check what the user already has before creating or updating searches' provides explicit when-to-use context. It also mentions plan limits and that it doesn't count toward monthly searches, but lacks explicit alternatives or 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?

The description adds one useful behavioral note: 'Does not count toward your monthly searches.' This goes beyond the annotations (readOnlyHint, destructiveHint, etc.) to clarify quota impact. However, it does not disclose other behavioral traits like whether the feedback is stored, who sees it, or any rate limits. With annotations present, the bar is lower, but the added value is marginal.

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 two sentences long and front-loaded with the primary purpose. The second sentence provides a relevant behavioral note. No wasted words, every component earns its place.

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

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

Despite having 10 parameters and no output schema, the description is very brief. It does not explain the expected return value, the typical use case in more detail, or how to structure feedback for different action types. While the schema covers many parameters, the description fails to provide a holistic overview, leaving a noticeable gap for a tool with this complexity.

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 70%, meaning most parameters are already explained in the schema. The description lists some actions (bug, data_issue, irrelevant, praise) that overlap with the schema's enum descriptions, adding little new meaning. It does not clarify any parameters beyond what the schema provides, so it stays at the 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 clearly states the tool's purpose: 'Report bugs, data issues, or feedback.' It lists specific action types (bug, data_issue, irrelevant, praise) which distinguishes it from sibling tools focused on searching or saved searches. However, it could be more explicit about the scope (e.g., feedback on search results or the platform itself), leaving slight ambiguity.

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 a clear context for when to use the tool ('Report bugs, data issues, or feedback') and implies usage via the listed actions. It does not explicitly discuss when not to use it or provide alternatives, but there are no obvious sibling tools for feedback, so the guidance is sufficient yet not highly detailed.

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

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

Annotations are minimal (all false), so the description carries the burden. It discloses plan limits, free tier constraints, that saving does not count toward monthly searches, and recommends broad filters to avoid missing results. This goes beyond the annotations and gives the agent useful context for user expectations, though it does not detail alert delivery mechanics or confirmation 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 with clear sections (main, workflow, filter tips, plan limits), but there is redundancy between the opening paragraph's free tier mention and the later PLAN LIMITS section. Minor trimming would make it more concise, though the organization makes it easy to scan.

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 (5 params, nested objects, plan-dependent cadence), the description is thorough: it covers purpose, workflow, filter semantics, plan limits, and quota impact. There is no output schema, but for a save operation the description provides sufficient context for an agent to execute correctly and set user expectations.

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%, but the description adds valuable FILTER TIPS with specific guidance for itemTypes ('grant' includes fellowships/SBIR), sourceTypes, geography, sourceContext, and the recommendation to keep filters broad. This enriches the parameter meanings beyond the already-detailed 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 clearly states 'Save a search query for email alerts' and explains the resulting behavior (daily/weekly notifications). It distinguishes from siblings like update_saved_search, list_saved_searches, and delete_saved_search by focusing on the creation of a saved search with alert cadence.

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 RECOMMENDED WORKFLOW explicitly instructs when to use this tool, when to use alternatives (list_saved_searches first, offer update_saved_search if similar exists), and how to validate with search_grantsplus/search_procurement first. It also provides plan limit guidance, clarifying which cadences are available on each tier.

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 mark readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context beyond those: the release is QA-gated, limited to 3,678 profiles, covers IRS tax years 2018–2026, and calls count against the monthly quota. It does not mention pagination or result shape, but the annotations carry the safety burden.

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, all information-dense: main action, release scope, temporal coverage, explicit exclusions, and quota impact. The action is front-loaded and there is no filler or redundant phrasing.

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 essential operation, constraints, exclusions, and quota. Since there is no output schema, it does not specify the exact result fields, and pagination is unspecified. Given the simple 4-param schema and annotations, it is substantively complete, though a sentence describing the return shape would improve 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?

Schema has 100% description coverage, so the baseline is 3. The description reinforces the two accepted query forms (full legal name or EIN) and the unavailability of mission/topic queries, which mostly duplicates schema text. It adds the tax-year coverage range, but that is not parameter-specific, so little extra meaning is added over the structured properties.

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 'look up', resource 'private foundation', and the lookup keys 'full legal name or EIN'. Explicitly narrows the scope to the QA-gated Foundation Intelligence release with 3,678 profiles, distinguishing it from sibling search tools that cover grants/procurement or mission/topic.

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 makes the exclusion clear ('Mission/topic discovery and grant-purpose search are withheld') and implies the tool is only for exact name/EIN lookup, but it does not name any alternative tool (e.g., funders_for_cause or find_funders_of) for those withheld use cases. Guidance on when to use this vs. siblings is implied rather than 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?

Annotations already declare readOnly/idempotent/non-destructive, so the description's added value is the behavioral layer annotations cannot express: ingestion-lag differences by plan tier (1 day paid, 10 days free), that the call counts against a monthly quota, and that a batch consumes only 1 call. These are exactly the operational facts an agent needs before invoking.

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?

Front-loaded with purpose then usage then batch/freshness/quota facts; every sentence carries information. It is long relative to a simple search, though the length is driven by genuinely useful quota and tier disclosure rather than 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 20-parameter, nested-object tool with no output schema, the description covers the dominant modes (single query, batch, foundation inclusion) and the cost/freshness model. It omits guidance on the browse/filter-only parameters (source, organization, since, status), leaving those to the schema, which keeps it just short of 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?

Schema description coverage is 100%, so the schema already documents all 20 parameters, and enum/min/max constraints are in the schema. The description restates the batch-mode contract (2-5 queries, parallel, dedupe, replaces batch_search_grantsplus) but adds little semantic detail beyond it, so the baseline 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 and resource (search grants, prizes, fellowships, SBIR/STTR, private foundations) and explicitly scopes out procurement/contracts, which separates it from search_procurement and search_grants_and_procurement. An agent can pick this tool without opening the 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?

"Use when user wants: funding, grants, fellowships, research money, SBIR, foundation grants" plus concrete examples gives clear positive guidance, and the procurement exclusion gives a negative boundary. It stops short of naming the alternative tool to use for procurement, so it is strong context rather than fully explicit routing.

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 (readOnly, idempotent, non-destructive), but the description adds substantial behavioral context beyond them: batch mode is a paid feature that counts as one monthly search call, free-plan listings lag paid plans by 10 days, and the exact response semantics of place_of_performance_state (matched/unknownServed/otherStateExcluded) including how location_strict changes demotion to exclusion.

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?

Front-loads purpose, triggers, and examples before the dense operational detail, and every sentence carries information. The place-of-performance clause is a single sprawling parenthetical with an embedded tangent about unparseable geography, which hurts readability but not density.

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 20-parameter, nested-object tool with no output schema, the description covers cost/rate-limit behavior, batch-mode substitution, alias precedence, and the shape of the geography response fields. What is missing is any statement of return-value structure for the ordinary (non-geo) case, which the absent output schema leaves undocumented.

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%, so the schema already documents all 20 params and the baseline is 3. The description goes further by explaining cross-parameter interactions the schema only hints at: alias precedence (place_of_performance_state vs pop_state, posted_within_days vs new_within_days), that batch mode ignores query and swaps in the batch params, and what the placeOfPerformance response fields mean.

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 and resource ('Search government contracts, RFPs, RFIs, BAAs, and solicitations from SAM.gov') and explicitly positions itself against both a data source (searching SAM.gov directly) and a sibling ('this replaces the former batch_search_procurement tool'). An agent can identify the tool without opening the 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?

Gives explicit trigger phrases ('Use when user wants: contracts, RFPs, procurement, bids, government work') plus concrete query examples, and explains when to switch to batch mode (queries[] with 2-5 variations). It does not, however, state when to prefer the close sibling search_grants_and_procurement or search_grantsplus over this tool.

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?

Discloses 'Opens browser login' which is a disruptive side effect not captured by annotations, and the quota note adds useful context. Annotations (openWorldHint, readOnlyHint) are supplemented, not contradicted.

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 front-loaded with the primary action, followed by two key behavioral notes. 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?

Simple tool with no params or output schema; description covers purpose, OAuth method, browser interaction, and quota impact. Sufficient for an agent to invoke 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?

Zero parameters, schema coverage 100%, so no parameter explanation needed. Baseline for 0 params is 4.

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 'Authenticate existing subscriber via OAuth' – a specific verb, target, and method. Clearly distinguishes from sibling tools like get_account_status or check_connection by specifying it's the login flow.

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 context: it's for authentication, and notes 'Does not count toward your monthly searches' which implies it's a separate action. But doesn't explicitly state when to use vs alternatives or when not to use, so not 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?

Adds 'Can only update your own saved searches' (permission), 'Does not count toward your monthly searches' (quota), and 'The response confirms what was updated' (return behavior). These go beyond annotations. Doesn't mention that filters are replaced wholesale, but schema covers that.

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 short paragraphs, each with a distinct purpose: intro, modifiable fields, tip/quota. No unnecessary 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?

Covers the key aspects: what it does, auth constraint, quota, and response behavior. With a high-coverage schema, this is sufficient, though it could clarify behavior when only id is supplied.

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 covers 100% of parameters, so description's MODIFIABLE FIELDS list largely restates schema. The cross-reference to save_search schema for filters is useful, and the cadence enum values are repeated, but no additional semantic depth is added.

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 'Update a saved search' and lists modifiable fields (query, filters, cadence, name, quality settings). This clearly distinguishes it from siblings like save_search (create) and delete_saved_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?

Tips to call list_saved_searches first and update only fields that need to change provide clear workflow. The restriction 'Can only update your own saved searches' sets a condition, but it doesn't explicitly say when to use this over save_search or delete_saved_search.

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?

Even with readOnly/idempotent annotations, the description discloses substantial non-obvious behavior: round-robin sampling so one bulk harvester cannot own the digest, the meaning of `windowCoverage.sourcesSampled` absent vs. 0, `ceilingTruncated` only appearing in recency mode, and the honest held-back count under the free tier. 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 description is long, but it is front-loaded with the core purpose and then structured around genuinely important behavioral edge cases that are not visible in the schema or annotations. Each sentence adds operational value, though the density around `windowCoverage` semantics makes it heavier than a minimal description would be.

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?

There is no output schema, so the description carries the burden of explaining return semantics. It covers `newSince`, `windowCoverage`, `sourcesServed`, `windowIncomplete`/`incompleteReason`, `ceilingTruncated`/`hardCeiling`, ordering behavior in both recency and relevance modes, and free-tier behavior. That is sufficient for an agent to invoke and interpret 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 high at 91%, so the baseline is 3, and the description adds extra meaning on top: `since` is the stateless alternative to `days`, `omit query entirely` for a pure digest, and `newSince.newest` is the value to reuse as the next watermark. It doesn't enumerate every parameter, but the schema already covers those details.

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 by naming the tool's specific role: a dedicated 'what's new since I last checked' tool for recurring agent checks, and then states it 'Returns opportunities FundingLandscape ingested in the last N days (default 7), with a newSince summary.' It also differentiates itself from the search siblings by framing itself as the alternative to 'remembering the new_within_days param on a 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?

Usage is explicitly contextualized: use this tool instead of the search tools' new_within_days/posted_within_days parameter, and 'omit query entirely for a pure recency digest across everything new.' It also gives concrete stateless-watermark instructions: pass `since` (ISO 8601), store the response's `newSince.newest`, and pass it back next time.

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