Programscape

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

Annotations already cover the safety profile (readOnly, non-destructive, idempotent, closed-world), and the description adds meaningful semantic guarantees beyond that: standings are not assertions of qualification, amounts are per-program figures not totals, and no provider is ranked the winner. It also notes the result indicates how the review can be saved. This is above the annotation baseline, though it doesn't explain return format or idempotency implications.

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 very long sentence followed by several short clauses. It's dense and somewhat front-loaded, but the long compound sentence is hard to parse quickly and the final sentences about standings, amounts, and ranking are fragmented. It earns its place but could be structured more cleanly.

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 a simple single-parameter tool with full schema coverage and annotations covering behavior, the description adds substantial value: what the result contains (read of what matters, programs worth time, what can wait) and semantic caveats. No output schema exists, so the description appropriately describes the return shape at a high level. It is close to complete for 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 100% and the schema already documents the answers object thoroughly with keying, length limits, and an example. The description reinforces this by listing the fact categories (stage, funding, tools, company type, earlier answers) and noting that missing facts stay unknown, adding useful semantic context about partial data. Baseline is 3, so this earns a 4 for the extra framing.

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 what the tool returns (a Programscape review for a founder built from their company facts) and names the query it answers ('which startup credits, programs or perks fit a company'). It is clear and specific, but it doesn't explicitly distinguish it from siblings like compare_programs or search_programs, relying on the reader to infer the difference.

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 rather than explicit: the tool is for questions about which credits/programs/perks fit a company. There's no explicit when-not-to-use guidance or direct routing to alternatives such as search_programs or compare_programs, which would be needed for a higher score.

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 the safe read-only, idempotent, non-destructive, closed-world profile. The description adds useful behavioral context that results are grouped as families and deliberately present no winner or score, but it omits return format and any pagination 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 a single, front-loaded sentence with zero waste. It efficiently conveys the output structure and the neutral comparison stance.

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 low complexity (two optional enum parameters, no output schema) and rich annotations, the description is nearly complete. It could better explain what a 'family' of programs entails or what the side-by-side output actually looks like, since no output schema is provided.

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 two optional enum parameters are fully documented in the schema. The description adds no syntax or format details beyond what the schema provides, making the baseline 3 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?

States a specific verb ('Returns'), resource ('families of programs'), and scope ('across providers, side by side'), which distinguishes it from search_programs and get_program. However, it does not explicitly name the sibling tools it differs from, leaving some inference to the agent.

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 or when-not-to-use guidance. The description implies a comparison use case but never mentions alternatives like search_programs for listing or get_program for details, so an agent must infer 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?

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: the record is 'reviewed' and includes a 'date checked,' signaling curated, freshness-tracked data. It does not explain error behavior for invalid ids, but that is a minor gap given the rich 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?

A single front-loaded sentence that states purpose and enumerates return fields with zero filler. Every word earns its place.

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

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

For a simple read-by-id tool with complete parameter documentation and strong annotations, the description adequately explains purpose and return content. The only missing element is explicit routing guidance versus sibling search_programs, which keeps it from being fully 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 single 'id' parameter's format and examples are fully documented in the schema. The description adds no additional parameter semantics, which is the correct baseline when structured data already does the work.

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 (returns) and a precise resource (one program's reviewed record), then enumerates the record's contents (offers, decision-makers, exclusions, sources, date checked). This distinguishes it from sibling tools like search_programs (multiple results) and compare_programs (comparison).

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 you have a program id and want its details, but gives no explicit when-to-use, when-not-to-use, or alternative tools. It never mentions search_programs as the way to find an id, leaving that inference to the agent.

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=false, so safety is covered. The description adds value beyond them by disclosing the shape of the returned content (answers, kept/set-aside programs, review) in the absence of an output schema. It says nothing about permissions or multi-plan behavior, but the annotation bar is low.

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 with zero filler; the return contents are front-loaded and the audience is stated last. 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?

With annotations covering the safety profile and a fully documented single parameter, the description's main remaining job is describing the return payload, which it does. Nothing critical is missing, though it could note behavior when no plan exists.

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 single optional planId is fully documented in the schema, including the default to most recent. The description adds no parameter-level meaning beyond that, 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 precise verb (returns) and resource (the founder's saved Programscape plan), then enumerates its contents: answers, kept/set-aside programs, and the current review. This is clearly a read of a persisted plan, distinct from the mutating siblings update_my_plan and save_plan_draft, though it never names an alternative 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?

The sentence 'For a returning founder asking where things stand or what to do next' gives a concrete usage context that maps well to an agent trying to re-orient a user. It stops short of stating when NOT to use it (e.g., to edit the plan, use update_my_plan) or naming 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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real context beyond them: founder counts under 3 are withheld (a privacy rule that affects interpreting results), and it reports 'when the partner's own system last read its feed' (freshness semantics). It omits return shape/pagination, keeping it from 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?

It is a single dense sentence front-loaded with the audience and purpose, with the read-only constraint trailing. Every clause carries information (items surfaced, count-withholding rule, feed freshness), though the heavy parenthetical stacks make it slightly sprawling.

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 input schema parameters and no output schema, the description must convey what comes back, and it does so by listing the reported signals. For a zero-arg read tool whose annotations already establish safety, this is largely complete; only the exact structure/ordering of the response is unstated.

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, which is the baseline-4 case per the rubric; there is nothing for the description to disambiguate. The description correctly implies no input is required to obtain the full admin view.

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

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

The description names a specific verb+resource: an admin-facing read of a venture firm's/studio's partner perks list, enumerating what it surfaces (deals due to re-confirm, changed/closed linked programs, unchecked imports, per-invite founder counts, last feed read). It is unambiguous what the tool returns. It does not explicitly differentiate itself from lookalike siblings such as portfolio_perks, so it stops short of a 5.

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

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

It scopes the audience to the perks-list admin and frames the use case as 'what needs a look.' It also closes off the wrong usage: 'Reads only; changes are made on the admin page,' telling the agent not to attempt mutations here. No explicit alternative sibling is named, so 4 rather than 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 readOnly=true, idempotent=true, openWorld=false, so the safety profile is covered. The description adds genuinely useful behavioral context: results come 'in the partner's own words', are 'labelled as the partner's terms', and include 'live records', clarifying provenance and freshness. It does not cover what happens when the founder has no perks, nor any empty/error 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?

It is a single sentence, but an overstuffed one with nested clauses and parentheticals ('for example PSL's') that delay the point. The conditional gating is front-loaded, which helps, though the sentence could be split into 'returns X; requires Y' for clarity.

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 is the sole source for return content, and it does name the two result categories (negotiated deals and public programs) plus attribution. It stops short of describing result shape, ordering, or behavior when no perks were joined, leaving a modest gap for a zero-parameter retrieval tool.

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 there is nothing for the description to clarify; the baseline of 4 applies. No parameter-level gaps exist to compensate for.

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 verb is 'returns' and the resource is the portfolio's negotiated deals plus pointed-to public programs, which is reasonably specific. However, the purpose is buried inside a long conditional clause ('If the founder joined... perks'), so the core action is hard to extract at a glance, and it never distinguishes itself from the likely-admin sibling partner_perks_admin.

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 opening condition ('If the founder joined a venture firm's or studio's perks on Programscape') implies when the tool is applicable, which is useful implied gating. But no alternatives are named for the case where the condition is false, and no explicit when-not guidance is given.

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=true, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds the behavioral note that 'a fact the founder hasn't given stays unknown,' which hints at state handling but is vague and doesn't fully explain what that means (e.g., no defaults, requires prior input). With annotations covering safety, this is marginally informative.

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 short sentences and front-loads the main action. However, the second sentence is cryptic and doesn't clearly earn its place—it leaves the agent guessing about its meaning. The structure is concise but lacks clarity.

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 has no parameters and rich annotations, the description should still clarify its role among siblings and what 'questions' and 'review' mean in this context. The description is too vague and doesn't provide enough context for an agent to understand when and why to use it, especially without an output schema.

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 parameter semantics are not applicable. The baseline for zero parameters is 4, and the description doesn't need to compensate for schema coverage since there are no parameters to document.

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 says it 'returns the shared questions, with their answer options, that shape a founder's review.' While it states a verb (returns) and resource (questions with answer options), the phrase 'shape a founder's review' is vague and doesn't clarify what a review is or how this differs from siblings like build_route or get_program. The second sentence about unknown facts is cryptic and doesn't aid purpose clarity.

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 tool versus alternatives. Sibling tools like build_route or get_program are not mentioned. The description implies it's for retrieving questions that influence a route, but doesn't state the context or prerequisites for calling it.

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 this is a non-read-only, non-destructive, non-idempotent mutation, so the description is free to add value elsewhere and does: the draft is one-day/24-hour lived, the return value is a link opened on programscape.com, and finalization uses an email code with no password. The auth flow and expiry are genuinely beyond what the structured fields convey.

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

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

Three front-loaded sentences, each carrying distinct information: the save action and return link, the finalization flow, and the expiry window. The 'one-day draft' and 'works for 24 hours' phrasing is mildly redundant, costing a point.

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 two-parameter mutation tool with full schema coverage and no output schema, the description covers the essentials an agent needs: the draft lifetime, the returned link as the tangible output, and the email-code finalization step. Remaining gaps (non-idempotent repeat behavior) are already handled by annotations.

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 fully documents both answers and keep with examples and constraints, so the schema carries the load. The description only loosely ties them together ('with their answers and kept programs in place') and adds no format or edge-case detail beyond that, so 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 (Saves) and resource (a founder's review as a one-day draft), and adds the side effect of returning an openable link. That is enough to distinguish it from read-oriented siblings like my_plan and get_program, though it never names an alternative 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 implied rather than stated: the tool produces a draft link the founder later finalizes on programscape.com, so an agent can infer this is the pre-finalization save step. There is no explicit when-to-use, when-not, or comparison against update_my_plan/save-type 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?

Annotations already declare the operation safe and idempotent (readOnlyHint, destructiveHint false, idempotentHint true), so the safety burden is lifted. The description still adds real context: the catalog is curated/reviewed, each result carries its official source and last-checked date, and listings are explicitly not a claim of eligibility. Return-shape and pagination are not detailed, keeping this below 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?

Three sentences, front-loaded with the core action and scope, then provenance details and finally a caveat. No filler or redundancy. Slightly more preamble than strictly necessary compared to a one-line scope statement, so not a full 5.

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 no-required-param search tool with a fully documented schema and no output schema, the definition covers scope, provenance of results, and the implications of a listing. The only gap is behavioral detail around result ordering or pagination, which is minor given the limit parameter is already documented.

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 kind, limit, query and provider including defaults and bounds. The description only repeats the provider examples (AWS, Google Cloud, Stripe), adding no syntax or semantics beyond the schema. 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 ("Searches the reviewed catalog of startup credits, programs, support and product discounts") and enumerates the provider scope, so the agent knows exactly what domain is covered. It does not, however, distinguish itself from siblings like get_program, compare_programs or whats_changed, which also operate on this catalog.

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 rather than stated: the kind/query/provider parameters signal that this is a browse/filter entry point. There is no explicit guidance on when to use it instead of get_program or compare_programs, and no prerequisites or exclusions are given. The closing caveat about qualification is a useful qualifier but not routing guidance.

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

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

Annotations flag destructiveHint=true and idempotentHint=false, and the description usefully narrows that destructiveness by stating 'Only what is sent changes; everything else in the plan (notes, progress, contacts) stays as it is'. It also discloses the upsert behavior. Auth requirements and concurrency behavior are unstated, so not 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?

Three sentences, each earning its place: what gets saved, the create-if-none condition, and the partial-merge guarantee. The most safety-relevant fact (only sent items change) is front-loaded alongside the operation.

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 4-param, no-required-field, no-output-schema mutation tool, the description covers upsert behavior and partial-merge semantics well. It does not address what happens if a program id appears in both keep and setAside, nor any authorization scope.

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 keep/setAside/answers/planId are already documented in the schema. The description names the same concepts (answers, programs to keep, set aside) but adds no field syntax, constraints, or conflict resolution beyond the schema 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?

States a specific verb (Saves/updates) and resource (the founder's own Programscape plan) plus the sub-operations: new or changed answers, programs to keep, programs to set aside. This distinguishes it from save_plan_draft (drafting) and my_plan (reading), both visible 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?

Gives clear operating context: use it to save answers and program choices, and it will create the first plan if none exists (upsert). It does not explicitly name when to prefer save_plan_draft or my_plan instead, so it stops short of full alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structured data. The description adds one useful behavioral detail beyond that: results are 'dated and sourced,' telling the agent the response carries provenance and timestamps. It says nothing about how far back changes are tracked or how completeness is determined, so it is a modest addition.

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

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

A single front-loaded sentence with no filler and no repetition of the title. The phrasing 'Programscape's latest checks against the providers' own pages' is slightly convoluted for what is essentially a change feed, but nothing is 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?

For a one-parameter, read-only tool with rich annotations and full schema coverage, the description supplies the key missing context (output is dated and sourced). With no output schema, more detail on how changes are represented would help, but the essentials for correct invocation are present.

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 single optional limit parameter is fully documented in the schema (max 10, default 3). The description adds no meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb (returns) and resource (what the latest re-checks against providers' own pages found), which is clear enough for an agent to know this is a change/update feed. It does not explicitly distinguish itself from any sibling, but none of the siblings (search_programs, get_program, compare_programs) overlap with a 'what changed since last check' feed.

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 when-to-use guidance, no prerequisites, and no named alternative. The phrase 'latest re-checks' implicitly suggests freshness-oriented usage, but the agent is left to infer that this is the right tool for detecting program changes rather than calling search_programs or get_program.

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