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 read-only, idempotent, and non-destructive; the description adds substantial behavior beyond that: default ~4KB/10 results, detail_level and max_results trade-offs, total available count, the placeOfPerformance aggregation semantics under pop_state and location_strict, and monthly search quota impact. No statement contradicts 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 most important routing information (deprecation and preferred alternative) is front-loaded, followed by the core action, then behavior and cost. The prose is dense, with the pop_state explanation and quota note adding complexity, but no true filler; it is longer than minimal but proportional to an 11-parameter, no-output-schema 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?

Given no output schema, the description covers the main invocation risks: deprecated status, response size, count of results, ability to request more, a subtle placeOfPerformance behavior, and quota cost. It does not enumerate the full result payload, but the schema's detail_level descriptions fill that gap, so it is complete enough for correct invocation.

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

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

Schema coverage is 91%, so the per-parameter descriptions carry most of the semantic burden. The tool description adds cross-parameter value by tying detail_level/max_results to response size and by explaining the response-shaping effect of sam_filters.pop_state/place_of_performance_state and user_context.location_strict.

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 leads with an explicit self-identification as 'DEPRECATED ALIAS' of search_procurement and then states a concrete action and resource: 'Search federal contracts (SAM.gov) comprehensively.' The batch fan-out over queries[] gives a clear behavioral boundary that distinguishes it from the one-query search_procurement sibling.

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

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

It explicitly directs the agent to 'prefer search_procurement with a queries[] array' and says this tool is 'Kept for backward compatibility,' which is an unambiguous when-not-to-use instruction. It also supplies operational usage context such as response-size controls and monthly quota counting.

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. The description adds valuable operational context beyond annotations: 'Returns success immediately with no database calls' and 'Does not count toward your monthly searches.' It also clarifies that it validates authentication, which is not disclosed by annotations. This is a good enhancement of the annotation-only 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 is three sentences, each with a distinct purpose: purpose, usage guidance, and a side-effect note. It is front-loaded with the core function and contains zero fluff or repetition. Every word 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?

For a simple health-check tool with zero parameters and no output schema, the description covers everything needed: what it does, when to use it, what it confirms, and its side-effect-free nature. The lack of an output schema is fine because the description explicitly states it returns success. This is fully complete for the tool's 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?

The tool has zero parameters, so the input schema is trivially complete. The description correctly does not mention any parameters. Per the baseline for zero-parameter tools, a score of 4 is appropriate since there is nothing to add semantically.

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 'Verify MCP server connectivity' and specifies that it 'Returns success immediately with no database calls.' This distinguishes it from all sibling tools that perform data operations, making it instantly clear when this tool is the relevant one.

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 direct usage guidance: 'Use this FIRST if experiencing tool errors' and explains what a successful response confirms (server reachable, authentication valid). It does not explicitly state when not to use it, but the 'FIRST' directive effectively communicates priority, which is strong guidance despite lacking exclusions.

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?

Given that annotations already mark the tool as read-only and idempotent, the description adds substantial behavioral context: the compact mode output structure (merged `results`, section counts/index ranges), the full mode with descriptions and arrays, exclusion of non-biddable notices and past/undated rows, and billing implications (paid feature, counts toward monthly searches). It goes well beyond annotations and sets clear expectations.

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 front-loads the purpose and then explains modes, exclusions, category, and billing. Each sentence adds useful information, but the length and density make it slightly less scannable than a more structured format. It is appropriately detailed for the complexity of the 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?

The tool has four parameters, no output schema, and a moderately complex response structure. The description compensates by describing the default and full output shapes, the exclusion rules, and the category filter. It does not explain potential conflicts between `days` and `weeks`, but that is a minor gap. Overall, it is complete enough for an agent to invoke the tool appropriately.

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 describes all four parameters at 100% coverage, so the baseline is 3. The description adds meaning by explaining how `compact:false` alters the output structure (full sections arrays) and by giving a concrete example for `category` ("procurement" for contracts only). This enriches the schema descriptions without redundancy.

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 'Get upcoming funding deadlines,' which clearly identifies the tool's function as retrieving a calendar of deadlines. It further specifies the resource (funding deadlines) and context (planning an application schedule). This distinguishes it from sibling search tools that return broader matching results, making the purpose unambiguous.

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

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

The description clearly sets the context for use: planning an application schedule and wanting a balanced view of grants and procurement. It explains the compact mode as default and how to opt out, and it gives an example of restricting by category. It does not explicitly name alternative tools to use instead, so it misses the 'when-not-to-use' element, but 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?

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?

Beyond annotations (read-only, idempotent), the description discloses key behavioral traits: uses vector embeddings, returns similarityScore and matchExplanation, and notes that it is a paid feature counting toward monthly searches. This provides useful context about how the tool behaves and its limitations.

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

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

The description is well-structured and front-loaded with the primary purpose. Each sentence adds value: purpose, output details, use case, technology, and constraints. Slight redundancy between 'semantic similarity' and 'vector embeddings' but not excessive.

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 does a good job explaining return values (similarityScore, matchExplanation). It covers the conceptual basis (semantic similarity) and operational constraints (paid, monthly count). Minor gaps include error behavior or handling of no similar results, but overall adequate for an agent to select and 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?

Schema description coverage is 100%, so parameters are well-documented in the schema. The description does not add much parameter-specific meaning but does clarify the output semantics (similarityScore, matchExplanation), which helps understand what the parameters affect. Baseline 3 is appropriate given 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 clearly states the tool's function: finding opportunities similar to a given one using semantic similarity, and distinguishes it from keyword-based search tools. The verb 'Find' plus the resource 'opportunities similar to a given one' is specific and differentiates from 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?

Explicitly states when to use: 'Useful when user likes one result and wants more like it.' It also contrasts with keyword matches, implying the alternative of search tools. Does not explicitly name alternatives or exclusions, but provides clear usage context and constraints (paid feature, monthly searches).

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?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the bar for additional behavioral disclosure is lower. The description still adds substantial context: beta/QA-gated status, Plus/Pro section requirements, responsible-use limits, exclusion of named-person grant recipients, and the private-foundation-only constraint. No contradiction with annotations.

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

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

The description is long but every sentence carries distinct information: purpose, coverage, plan tiers, return semantics, exclusions, and quota behavior. It is well organized and front-loaded with the core purpose before diving into section-specific details.

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

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

For a complex 12-parameter, 5-section tool with no output schema, the description covers scope, access tiers, exclusions, and return semantics for key sections. It does not describe the overall response envelope or error behavior, but the detail provided is strong enough for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3 because the schema already documents every parameter. The description adds genuine meaning beyond the schema by explaining what each section returns and the access tier required—particularly for section, leadership, and federal_connections—which helps an agent choose parameter values correctly.

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

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

The description opens with a specific verb and resource: 'Get the current profile for a PRIVATE foundation by EIN.' It further clarifies the tool's scope by naming exact sections (grant history, repeat grantees, leadership, federal connections) and exclusions, so an agent can distinguish this from broader foundation-search siblings.

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

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

The description gives clear context: this is for private foundations with known EINs, covers IRS tax years 2018–2026, and does not count toward monthly searches. It does not explicitly name an alternative tool for discovery or broad searching, so it stops short of full when-to-use versus 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 meaningful behavioral context beyond the annotations: it warns against constructing IDs (which implies failure modes for malformed IDs) and reveals that the tool does not count toward monthly search quota. Annotations already cover read-only, idempotent, and non-destructive traits, so this extra context is valuable.

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, followed by a salient usage warning. 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 single-parameter retrieval tool with no output schema, the description provides the essential ID provenance rule and quota behavior. 'Full details' is somewhat vague but acceptable for a get-by-ID tool; the context is adequate.

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 already fully describes the id parameter with 100% coverage, including an example. The description repeats this instruction in the IMPORTANT note but adds no new technical detail beyond reinforcing that the ID must come from search results. Baseline 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 uses the specific verb 'Get' with the resource 'full details for a specific funding opportunity', making the function immediately clear. It also implicitly distinguishes from sibling search tools by requiring a specific ID from search results.

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

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

The description provides clear usage guidance: use the exact ID from search results, do not guess or construct IDs. It also highlights a benefit (does not count toward monthly searches) that helps the agent decide when to use this tool. However, it does not explicitly name an alternative tool for searching, relying instead on the phrase 'from search results.'

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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful context beyond annotations: the release is 'QA-gated', covers '3,678 profiles' and 'IRS tax years 2018 to 2026', and 'counts toward monthly searches'—useful operational and data-scope details.

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 with no filler: the first states the operation and scope, the second gives data coverage, and the third states limitations and quota impact. The core purpose is front-loaded and every sentence earns its place.

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

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

The definition provides release scope, dataset size, covered tax years, explicit exclusions, and quota metering, which is strong context for a search tool. With no output schema, it could describe the return shape, but the absence is a minor gap rather than a blocking one.

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 four parameters. The description reinforces the query parameter format ('full legal name or EIN') and repeats that mission/topic queries are unavailable, but it does not add new parameter-level detail beyond what the schema 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 uses a specific verb ('Look up') and resource ('private foundation') with explicit lookup keys ('full legal name or EIN'), and it adds release scope. It does not explicitly differentiate itself from sibling get_foundation, which may also fetch foundation data by identifier, so it stops short of a 5.

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

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

The description clearly excludes mission/topic and grant-purpose searches ('withheld until their source and quality contracts pass review'), telling agents when not to use the tool. However, it does not name alternative siblings that would handle those cases, so it lacks the full when-not/alternatives guidance 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 cover readOnly, idempotent, and non-destructive behavior; the description adds meaningful behavioral context beyond that. It discloses rate limits ('Free tier: 10 searches/month'), quota consumption ('Counts toward your monthly searches'), a data-delay policy ('free plan reaches the same listings after 10 days'), and the noise caveat ('can create noisy results'). None of this contradicts the annotations.

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

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

The description is front-loaded with scope, then routing, then plan constraints, and is information-dense for a tool with 15 parameters. It loses the top score because 'Use search_grantsplus or search_procurement for cleaner, more relevant results' partially restates the routing bullets, and the ALL-CAPS labels add visual noise.

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 combined search tool, the description supplies essential context: data scale, noise risk, routing logic, and usage quotas. The schema handles parameter semantics and even exposes result fields through the compact parameter description, so the missing output schema is a manageable gap. However, the description itself does not mention the at-least-one-of query/source/organization requirement, so it is not fully complete in isolation.

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 input schema documents every parameter in detail, including the anyOf requirement, NAICS filters, cursor pagination, and compact result fields. The description adds only high-level context for the query parameter rather than per-parameter detail, which is acceptable 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 specific verb and resource: 'MIXED search across all 35,264 opportunities from 231 sources' and explicitly says it 'combines grants AND procurement/contracts in one query.' It also differentiates itself from search_grantsplus and search_procurement, making the sibling distinction clear.

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

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

The ROUTING section gives explicit conditions: grants/funding/fellowships/prizes go to search_grantsplus, contracts/RFPs/procurement/bids go to search_procurement, explicit both-intent goes to this tool, and unclear intent should prompt the agent to ask the user. It also recommends the specialized tools for cleaner results, leaving no ambiguity about selection.

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

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

Annotations already mark this read-only/idempotent, and the description adds substantial operational behavior: it dedupes merged batch results, returns matching private foundations automatically, reveals paid vs. free freshness delays, and explains that a batch counts as one monthly search. No contradiction with annotations.

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

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

The description is a dense, well-ordered paragraph with the purpose front-loaded, followed by examples and the batch/plan details. Each sentence earns its place, and none of the schema detail is needlessly repeated.

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 tool with no output schema, the description covers selection criteria, batch mode, exclusions, and plan limitations. It does not explain queryless browse or all filtering options, but the 100% schema coverage fills those gaps, making the overall context sufficient.

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 adds examples and clarifies that queries[] replaces the old batch_search_grantsplus tool, but it does not add meaning for the many other parameters (limit, since, cursor, status, user_context, grants_filters, etc.) 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 starts with a clear verb+resource: 'Search grants, prizes, fellowships, SBIR/STTR, and private foundations.' It explicitly excludes procurement/contracts, which immediately differentiates it from sibling tools like search_procurement and search_grants_and_procurement.

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' gives an explicit trigger list, and the exclusion of procurement supplies a when-not signal. However, it does not name the alternative tools (e.g., search_procurement) for procurement-only requests.

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 readOnlyHint, idempotentHint, and destructiveHint annotations already present, the description adds substantial operational context: free vs. paid data lag, monthly search counting, batch deduplication and summing, ignored psc_code, and detailed placeOfPerformance demotion/exclusion behavior. This is exactly the kind of non-obvious behavior an agent needs and is not visible 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?

The description front-loads purpose and examples effectively, but it is very long and dense, repeating some details that already exist in the schema, such as batch-mode behavior and alias precedence. Each sentence carries some information, but the wall-of-text format and duplication make it harder to scan. It would benefit from paragraph breaks and tighter editing.

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 20 parameters, nested objects, and no output schema, the description is unusually thorough: it covers plan-tier data freshness, batch semantics, ignored filters, geographic matching caveats, and search-count impact. It does not provide a concise high-level statement of the overall result shape or pagination flow, which would be useful given the absent output schema, so it is not a 5.

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

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

The input schema already documents all 20 parameters, so the baseline is 3. The description adds real value beyond the schema by explaining batch-mode usage and its replacement of batch_search_procurement, clarifying the pop_state/place_of_performance_state alias semantics, and detailing how the state filter affects response fields. It does not deeply re-explain every parameter, but its additional semantics are meaningful.

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 is explicit and specific: it names the resource (government contracts, RFPs, RFIs, BAAs, solicitations from SAM.gov), the operation (search), and typical user intents with concrete example queries. It distinguishes itself from grants-focused siblings by leading with 'CONTRACTS & PROCUREMENT' and by explaining that its batch mode replaces the former batch_search_procurement 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 clearly states 'Use when user wants: contracts, RFPs, procurement, bids, government work' and gives examples, which is strong guidance. It also explains when to use batch mode via queries[]. However, it does not explicitly contrast this tool with grants-focused siblings or state when NOT to use it, so it falls just short of full when/when-not coverage.

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?

The description goes well beyond the readOnly/idempotent annotations by disclosing round-robin sampling across sources, windowCoverage field semantics, ceiling truncation behavior, and the difference between recency and relevance ordering. It also states that calls count toward monthly searches, which is important operational context.

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

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

The description is long and dense, but almost every sentence adds needed behavioral context, especially since there is no output schema. The purpose is front-loaded in the first sentence. Some repetition of 'pure recency digest' and the detailed windowCoverage semantics could be tightened, but the complexity justifies the length.

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 11 parameters, no output schema, and no required parameters, the description covers what is returned (opportunities plus newSince summary), the sampling and coverage behavior, ceiling truncation, stateless watermark usage, free-tier behavior, and search-count cost. An agent has enough context to call this tool correctly and interpret its 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?

Schema coverage is 91%, so the schema already documents most parameters. The description adds meaningful behavior beyond the schema: query presence changes the ordering mode, since enables a stateless watermark pattern, and days filters on ingest freshness rather than posted date. Some parameters (compact, cursor, user_context) are left to the schema, which is acceptable given high 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 names a specific verb (returns opportunities ingested in last N days), a specific resource (FundingLandscape opportunities), and a clear scope ('what's new since I last checked'). It explicitly differentiates itself from search tools by positioning this as the dedicated recency digest instead of remembering the new_within_days parameter.

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

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

It states this is for recurring agent checks and calls out the alternative pattern ('instead of remembering the new_within_days param on a search tool'). It gives concrete guidance: omit query for a pure recency digest, pass since for a stateless watermark, and narrow with query/status/source.

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