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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds the cause-slug prerequisite but says nothing about pagination behavior, result ordering, or what a browse returns, which with a lower bar for annotated tools yields an adequate rather than rich score.

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 tight sentences, no filler, with the primary scope statement front-loaded before the pointer to list_causes. Every sentence carries 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?

For a read-only browse tool with no output schema and a simple flat schema, the description covers the required parameter's semantics and the prerequisite tool. Only the sibling-tool boundary (search_nonprofits) is left unaddressed.

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 67%; page and take are self-documented in the schema, but cause has no schema description at all. The description compensates by defining cause as a single slug and giving example values (animals, climate), adding real meaning beyond minLength: 1.

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?

Specific verb (Browse) plus resource (Every.org nonprofits) and scope (one cause slug), with concrete slug examples (animals, climate). It explicitly routes to the sibling list_causes, so an agent can separate this from that tool, though it does not distinguish itself from search_nonprofits.

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 sentence 'Call list_causes for the published set' tells the agent how to obtain valid cause slugs, which is genuine prerequisite guidance. However, it never states when to prefer this tool over search_nonprofits or get_nonprofit, so the when-to-use condition is only implied.

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?

Against readOnlyHint=true, the description adds genuinely new behavior: the tool only builds a link and the gift completes on Every.org, so no transaction occurs in the tool itself, and amounts are USD. It does not mention auth requirements, whether repeated calls are cheap, or what invalid inputs do, so it falls short of 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?

Four short sentences, front-loaded with what the tool produces, with no filler. The telegraphic phrasing 'nonprofit is special-fundraiser' is slightly compressed and could be misread, but the overall structure is 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?

For a 22-parameter customization surface with a nested object (partnerMetadata) and no output schema, the description covers only the core path and never says what is returned (a URL string) or how the many optional parameters (methods, frequency, staging, webhookToken) affect the link. Adequate for the minimum viable call but incomplete for the full surface.

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

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

With only 55% schema description coverage across 22 parameters, the description must compensate but largely restates schema text ('Amounts are US dollars' vs. amount/minValue descriptions; special-fundraiser guidance vs. the nonprofit description). Roughly half the parameters (methods, frequency, noExit, exitUrl, webhookToken, partnerMetadata, themeColor, etc.) get no explanation 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 states a specific verb (build) and resource (Every.org donate URL) and clarifies the deferred outcome ('The donor completes the gift on Every.org'), which separates it from the read-only lookup siblings like get_nonprofit and get_fundraiser. An agent can identify this as a URL-construction tool without opening the schema.

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

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

It gives conditional parameter routing ('For a fundraiser, pass its slug', 'for a multi-nonprofit fundraiser, nonprofit is special-fundraiser') but never says when to prefer this tool over siblings such as get_fundraiser for retrieving a slug, nor any prerequisites (e.g., where the slug/EIN comes from). Usage is implied rather than framed as when/when-not.

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 openWorldHint=true, covering the safety profile. The description adds one genuinely useful behavioral edge case (multi-nonprofit fundraisers are addressed via 'special-fundraiser'), but says nothing about not-found behavior, auth requirements, or rate limits.

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

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

Two tight sentences, front-loaded with the core action and keys before the edge-case rule. No filler or redundancy.

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 two-key read with no output schema, the description covers identification adequately but omits any indication of what the fundraiser object contains or what happens on a miss. Annotations carry the read-safety story, keeping this at an acceptable but not complete level.

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 0%, so the description must compensate, and it does: it identifies both params as slugs and explains the special 'special-fundraiser' value for multi-nonprofit cases. It stops short of format examples or validation detail, so it is strong but not exhaustive.

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 ('Get') and resource ('Every.org fundraiser'), plus the two lookup keys. This is clearly distinguishable from get_nonprofit in practice, but the description never names or contrasts a sibling (e.g., get_fundraiser_raised), so differentiation is left to inference.

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?

There is no guidance on when to use this versus list_causes, browse_nonprofits, get_nonprofit, or get_fundraiser_raised, and no stated prerequisites. The only usage-flavored content is the special-fundraiser convention, which is really a parameter-value rule rather than a when-to-use signal.

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 openWorldHint, so the safety profile is covered. The description adds real value beyond them by disclosing the response payload (amount in both cents and US dollars, supporter count, goal) and by flagging the dual-unit formatting, which is non-obvious. It says nothing about error behavior for unknown fundraisers, so it is not fully complete.

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

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

A single dense sentence that front-loads the verb and resource, then lists the return fields. No filler, no redundancy with the title.

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 usefully enumerates the returned values, which is the right move for a read tool. However, for a two-required-parameter tool with 0% schema coverage, it leaves the caller without any notion of identifier formats or failure modes, so it is only minimally 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 0% and both required parameters (nonprofit, fundraiser) are bare strings with no format guidance. The description does not compensate at all – it never explains whether these are slugs, URLs, or EINs, or how nonprofit and fundraiser relate. With low coverage the description was expected to carry this burden and does not.

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 (get) and resource (how much an Every.org fundraiser has raised), and enumerates the data returned (amount, supporter count, goal). This clearly separates it from the sibling get_fundraiser, which presumably returns fundraiser metadata rather than totals, though the description never names that sibling explicitly.

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 only implied: an agent can infer it should call this when it wants a fundraiser's raised amount. There is no statement of when to prefer get_fundraiser over this tool, no prerequisites (e.g. needing a known nonprofit/fundraiser identifier first), and no 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the accepted identifier formats and the non-obvious EIN dash tolerance, but says nothing about return shape, not-found behavior, or errors.

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 tight sentences, zero filler, with the core lookup action front-loaded before the format caveat.

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 read tool with full schema coverage and no output schema, the description supplies enough to invoke it correctly. Minor omissions (error/not-found behavior) are acceptable given the annotation coverage.

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 goes beyond the schema by clarifying that the EIN is 9-digit and that dashes are permitted. That is a genuinely additive format detail not spelled out in 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?

States a specific verb (Get) and resource (Every.org nonprofit) with clear singular scope ('one'), which distinguishes it from the search/browse siblings. It does not name those siblings explicitly, so it falls 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?

Usage is implied by the singular identifier-based lookup, contrasting with list_causes and search_nonprofits, but there is no explicit when-to-use/when-not or named alternative. The agent must infer the routing from context.

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?

With readOnlyHint already declaring the safety profile, the description adds genuinely useful behavioral context: the data snapshot date (2023-06-06) and the warning that the live API may contain newer slugs. It doesn't mention pagination or result size, but the staleness caveat is the key operational risk and is disclosed.

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 short sentences, front-loaded with what is listed and what consumes it, followed by the freshness caveat. Every clause earns its place with no redundancy.

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 reference-list tool there is no output schema, and the description supplies what an agent needs: the content (cause slugs), the downstream consumers, and a data-freshness warning. Only minor gaps remain, such as whether the list is paginated or exhaustive.

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 are no arguments whose meaning needs explaining, and the description correctly implies a no-argument call.

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 gives a specific verb and resource ('List Every.org cause slugs') and explains the role the output plays for browse_nonprofits and a search causes filter. It doesn't explicitly contrast itself with siblings like search_nonprofits or get_nonprofit, but the reference-lookup purpose is 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?

It states the usage context clearly: call this to obtain cause slugs that feed browse_nonprofits and the search causes filter. There is no explicit when-not-to-use guidance or named alternative to avoid, but the intended workflow is evident.

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 openWorldHint, so safety is covered. The description usefully adds the result shape (name, EIN, slug, description, causes, profileUrl), which matters because no output schema exists, though it says nothing about ordering, pagination beyond the take cap, or result relevance.

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 short sentences, zero filler: the action and source are front-loaded, the return payload follows. Every clause 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 3-parameter read tool with no output schema, the description covers the source system and the returned fields while the schema covers every parameter. It is nearly complete; only the relationship to sibling search/browse tools is left implicit.

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%, with take, query and causes all documented in the schema itself. The description adds nothing about parameter syntax or interaction (e.g. that causes are OR-combined), so the baseline 3 applies.

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

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

States a specific verb and resource ('Search Every.org nonprofits by name') and even lists the fields returned. It does not, however, differentiate itself from overlaps such as browse_nonprofits or list_causes, which the agent must infer from the name alone.

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?

There is no explicit when-to-use guidance, no statement of when not to use it, and no routing to siblings (e.g. get_nonprofit for a single record, browse_nonprofits for unfiltered listing). The only hint, a reference to list_causes, lives in the schema for the causes parameter, not in the description.

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