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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on material behavior: a hard cap of ~50 candidate rows per section, exclusion of non-biddable notices and past/undated rows, coverage counts that are not exact eligible totals, and that it is a paid feature counting toward monthly searches. None of this is present in the structured fields.

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

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

Purpose is front-loaded and most sentences carry distinct information (mode behavior, row cap, exclusions, coverage semantics, cost). It is dense and slightly long, with the merged-results sentence doing a lot of work, but nothing is clearly 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, so the description must describe returns, and it does: results list shape, section counts/index ranges, sections.grants/sections.procurement, and coverage continuations. Combined with the exclusions and bounded-page caveats, an agent has everything needed 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, but the description adds real meaning beyond the schema by explaining what compact toggles (merged lean rows with section counts/index ranges vs full descriptions and full sections.grants/sections.procurement arrays) and what category does (default is a balanced grants+procurement view; "procurement" restricts to contracts only).

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 ("Get upcoming funding deadlines") plus the intent ("for planning an application schedule"), and its deadline-calendar framing clearly sets it apart from the sibling search_* tools. An agent can tell what it returns (merged deadline rows with daysUntil and section counts) 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 concrete usage conditions for its modes (compact default vs compact:false, pass category to restrict to one type) and warns that it returns a bounded page rather than a complete calendar, which steers correct expectations. It does not, however, explicitly name which sibling search tool to use instead for exhaustive discovery, so the alternative-selection guidance is implicit.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral context: it explains the beta QA-gated nature, what sections are included (leadership, federal-connections) and excluded (named-person grant recipients, grant-purpose text), tier requirements (Plus for grant history, Pro for leadership), and the fact it doesn't count toward monthly searches. This far exceeds annotation coverage.

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 core purpose and then systematically explains sections, tiers, exclusions, and counting behavior. It is longer than ideal, but every sentence adds distinct information, and the structure is logical. 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 complex tool with 12 parameters, 5 sections, and tiered access, the description covers the key contextual needs: section availability, exclusions, pagination differences (cursors vs page-number), tier requirements, and count behavior. No output schema exists, but the description adequately describes what the agent can expect in terms of data scope and constraints.

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% — every parameter has a detailed description in the input schema. The description does not add meaningful parameter semantics beyond what the schema already provides. Baseline 3 is appropriate since the schema carries the load; the description merely hints at section-specific filters without new syntax 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 clearly states the tool retrieves the current profile for a PRIVATE foundation by EIN. It specifies the exact scope (IRS 990-PF filers, 3,678+ foundations) and distinguishes itself from siblings like search_foundations by focusing on a single foundation's detailed data. The verb 'get' and resource 'foundation profile' are 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 implies usage for a single foundation lookup when an EIN is known, and notes the tool does not count toward monthly searches. However, it does not explicitly contrast with sibling tools like search_foundations or batch_search_grantsplus, nor state when NOT to use it. The context is clear but lacks explicit alternatives or 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?

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value beyond annotations by noting the search counts toward monthly searches (a usage limit) and that the dataset is QA-gated (a quality/access constraint). It does not explain return format or error handling, but given the strong annotation coverage, this is adequate.

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 fluff. The scoping statement ('full legal name or EIN') is front-loaded, followed by what is withheld, and then a usage note. Every sentence earns its place, and the description is short enough an agent can parse quickly.

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

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

The tool is simple with 4 parameters, all documented in schema, and an output schema is absent (so no need to describe return format). The description covers the main constraints: exact-name/EIN search, QA-gated data, withheld capabilities, and monthly counting. The only minor gap is the lack of detail on default behavior or edge cases, but for this complexity it's nearly complete.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds a note about query examples and reiterates that mission queries are not available, which reinforces a caution but doesn't add fundamentally new semantics beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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 looks up private foundations by full legal name or EIN, and specifies the exact dataset (QA-gated release with 3,678 profiles). It distinguishes itself from siblings like funders_for_cause or find_funders_of by explicitly noting that mission/topic discovery and grant-purpose search are withheld, which is crucial given the sibling list includes search_grantsplus and search_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?

The description makes it explicit when to use this tool: for full legal name or EIN lookups in the active release. It clearly states what is not available (mission/topic search) and that counts toward monthly searches, which is important for an agent to decide between this and alternatives. It also implicitly warns that mission queries will fail, so an agent should not attempt 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavioral context beyond that: the noisy-results caveat from mixing funding types, the 10-searches/month free-tier limit, and the freshness delay (free plan sees new listings after 10 days while paid plans see them the day they open). 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?

Front-loaded with purpose and the noise caveat in the first line, followed by compact ROUTING bullets, then plan details. Every section earns its place: the rate limit and freshness facts directly inform the choose-this-vs-sibling decision. The paid-plan phrasing is slightly redundant, but the overall structure is clean and scannable.

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

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

For a high-complexity tool (15 params, nested objects, no output schema), the description covers the critical non-schema context: routing guidance, noise tradeoff, monthly quota, and free-tier data-freshness delay. Output shape is partly recoverable from the compact parameter's field list. An agent has everything needed to decide whether to call it and what to expect.

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% — all 15 parameters including the extensive new_within_days/windowCoverage semantics and nested user_context are documented in the schema. Baseline 3 applies; the description doesn't add parameter-level meaning, though the 10-day freshness delay loosely contextualizes the recency 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?

States a specific verb+resource: 'MIXED search across all 28,696 opportunities from 232 sources — combines grants AND procurement/contracts in one query.' The title says 'Combined' and the description immediately names search_grantsplus and search_procurement as the alternatives, so an agent can tell this tool apart from its siblings without opening either 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 ROUTING block is explicit and exhaustive: grants/funding/fellowships/prizes → search_grantsplus, contracts/RFPs/procurement/bids → search_procurement, explicit BOTH → this tool, intent unclear → ASK the user first. It names alternatives, states the selection conditions, and even instructs the agent to ask rather than guess.

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 and idempotent, and the description adds substantial behavioral context: batch mode dedupes and merges parallel queries, paid plans see new listings earlier, free plans lag by 10 days, and a batch counts as one call. This goes well beyond the structured annotations.

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

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

The description is front-loaded with purpose, exclusions, and examples before moving to batch mode and pricing. It is longer than a minimal description, but every sentence carries operational information; the batch/pricing details stretch it but are not 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 tool with 20 parameters and no output schema, this description covers the core usage decision, batch-mode behavior, pricing implications, and query examples. It does not describe the queryless browse-by-source/organization mode or the return payload shape, but the schema covers the former and the latter is less critical for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all 20 parameters. The description adds some framing for the query (examples of grant-related phrasing) and recaps batch mode, but it does not explain parameter semantics beyond what the input 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 opens with a specific verb and resource: 'Search grants, prizes, fellowships, SBIR/STTR, and private foundations' and immediately distinguishes itself by stating it excludes procurement/contracts. It also gives concrete query examples, so an agent can tell it apart from search_procurement and search_grants_and_procurement without inspecting those tools.

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

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

It defines the intended trigger with 'Use when user wants: funding, grants, fellowships, research money, SBIR, foundation grants' and gives example natural-language queries. It notes the procurement exclusion and that batch mode replaces batch_search_grantsplus, but it does not explicitly name search_procurement as the alternative for contract 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 declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral context beyond these: batch deduplication behavior, place of performance reporting details, paid vs free plan delay, counting toward monthly searches, and the explicit note that sam_filters.psc_code is currently ignored. 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 well-structured: core purpose and usage are front-loaded, with detailed behavior organized into clear sections (batch mode, place of performance, paid vs free, counting). Each sentence provides distinct value—no redundancy or filler. The use of bolding and examples improves scannability for an agent.

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 20 parameters, nested objects, batch mode, and no output schema, the description covers return fields (placeOfPerformance, windowCoverage), filter semantics, mode differences, pagination, token budgets, and edge cases like psc_code being ignored. It thoroughly explains the behavior an agent needs to know to call the tool correctly.

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

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

While schema coverage is 100%, the description adds significant semantic value: alias relationships (pop_state for place_of_performance_state), precedence rules (posted_within_days wins over new_within_days), clarification that psc_code is accepted but not applied, and explanations of batch-mode-only parameters (offset, max_results, detail_level, max_response_tokens). It goes well beyond the schema's basic definitions.

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 searches government contracts, RFPs, RFIs, BAAs, and solicitations from SAM.gov, and explicitly contrasts with direct SAM.gov search by highlighting semantic search and NAICS filtering. It also notes batch mode replaces batch_search_procurement, distinguishing it from siblings and making its 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 explicitly states 'Use when user wants: contracts, RFPs, procurement, bids, government work' and provides concrete examples, giving clear trigger conditions. It also explains batch mode usage and that it replaces batch_search_procurement. However, it does not explicitly exclude alternatives like search_grantsplus for non-contract searches, so it lacks explicit when-not-to-use guidance relative to siblings.

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.