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

Annotations already declare readOnly, openWorld and destructive=false; the description adds that each call starts a new Apify Actor run under the caller's own account with their APIFY_TOKEN, which effectively explains the idempotentHint=false behavior and hints at per-run cost. It also discloses the return shape (dataset rows plus run and dataset IDs for paging), though it does not state what happens when a run yields zero notices or how long a run typically takes.

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 the core question ('Which EU tenders were published today?') followed by clearly labeled Returns/Behavior/Docs sections. The opening sentence restates the title almost verbatim, and the docs URL plus actor slug are somewhat redundant given the tool name, but overall there is little wasted prose.

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 9-parameter, no-required-param scraper with no output schema, the definition covers what it returns (one row per result plus run/dataset IDs for paging), how it executes (hosted Apify MCP gateway, caller's token), and its read-only nature. Nothing an agent needs in order to call it correctly 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?

Schema description coverage is 100% and the parameter docs are already detailed (CPV mapping to classification-cpv, date conversion to TED PD>=YYYYMMDD, expertQuery overriding all filters). The description adds no parameter-level meaning beyond the schema, 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 — returns TED (Tenders Electronic Daily) EU procurement notices with buyer, CPV, value, deadline and source link. The domain (EU TED) is named explicitly, which distinguishes it from the US/UK tender siblings without needing their schemas.

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 'When to use' block gives a clear triggering condition (needing EU TED notices with buyer, CPV, value, deadline). It stops short of naming alternatives such as uk-find-a-tender-scraper or usaspending-awards-scraper for non-EU jurisdictions, or explaining when to prefer expertQuery over the mapped filters.

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, destructive=false, openWorld=true, so the safety profile is covered; the description adds genuinely new facts: it starts a run of a named Apify Actor through the hosted MCP gateway, consumes the caller's own APIFY_TOKEN and Apify account, and returns run/dataset IDs for paging the full dataset. What it omits is run timing/synchronicity and what a partial or failed run looks like — relevant for a job-launching 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?

Clearly front-loaded and segmented into When to use / Returns / Behavior / Docs, so an agent can scan it quickly. The opening sentence largely restates the title, and the docs URL plus branding line add bulk without decision-relevant 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?

Return shape is adequately explained (dataset rows as JSON plus run/dataset IDs), which compensates for the missing output schema, and the auth/billing model is disclosed. But for a 19-parameter tool whose behavior changes drastically by mode, the description never explains monitor vs snapshot vs enrich vs rehashState, leaving the single most consequential control undocumented in both description and 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?

Schema description coverage is 95%, so the schema already carries the parameter burden and baseline 3 applies. The description only loosely gestures at the 'since' delta behavior and adds no meaning for mode, samBulk, enrichTopN, or incumbentMode beyond what the schema states — and 'mode' itself has no description in either place.

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?

Names a concrete resource and scope: 'Federal Contract Opportunities' pulling SAM.gov and Grants.gov notices into one feed, plus delta and source links. The combined-source scope implicitly separates it from the grants-only and USASpending siblings, but no sibling is ever named, so the differentiation is inferred rather than stated.

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 an explicit 'When to use' line: when you need new US federal contract opportunities plus grants in one feed, optionally delta-only since the last run. It gives no when-not conditions and never routes the agent to grants-gov-scraper or usaspending-awards-scraper for narrower needs, and the four modes (monitor/snapshot/enrich/rehashState) — the main behavioral fork — get no usage guidance at all.

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/openWorld/non-destructive, but the description adds genuinely non-obvious behavior: a run of the Apify Actor is started via the hosted MCP gateway, it uses the caller's own APIFY_TOKEN and Apify account, and the response includes run/dataset IDs for paging. It does not mention credit/cost implications of starting a run, which is the main remaining gap.

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?

Labeled sections (When to use / Returns / Behavior / Docs) are front-loaded and easy to scan. The opening restates the title and adds a rhetorical question ('Which federal grants are open right now?') that duplicates the purpose line, minor waste but not harmful.

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 10-parameter, no-required-input search tool with no output schema, the description covers purpose, return shape (one row per result plus run/dataset IDs), auth requirements and read-only nature. Only cost/credit behavior of the underlying Actor run is left unexplained.

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 every one of the 10 parameters is already documented in the schema, including the pipe-joined status format and the verified postedWithinDays values. The description adds no parameter-level meaning beyond naming agency, deadline and eligibility as returned fields.

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 Grants.gov and returns opportunity, agency, deadline, eligibility') with a clear geographic/source scope (US federal grants via Grants.gov). That scope implicitly separates it from the EU TED, UK tender and USAspending siblings, though no sibling is named 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?

An explicit 'When to use' line gives the condition: needing open US federal grant opportunities with agency, deadline and eligibility. It gives no negative guidance or named alternative (e.g. use the govcon feed for non-Grants.gov sources), so it stops 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 declare readOnly/openWorld/non-idempotent, yet the description still adds real value: it states that each call starts one run on Apify's hosted MCP gateway, that the caller's APIFY_TOKEN and Apify account are used (a billing implication), and that run/dataset IDs are returned for paging the full dataset. The 'starts one run' phrasing is consistent with idempotentHint=false.

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?

Sections are labelled (When to use / Returns / Behavior / Docs) and front-loaded, so an agent can skim it in one pass. Minor redundancy comes from restating the title verbatim and repeating the tool's scope in both the opening line and the 'When to use' block.

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 six parameters, no output schema and a hosted-run execution model, the definition covers everything an agent needs: selection criteria, returned data shape, authentication and account implications, and a docs link. Nothing material is left 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?

Schema coverage is 100%, so every parameter is already documented with formats, defaults and enum meanings. The description adds no parameter-level detail beyond the loose phrase 'for any city on Legistar', 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?

The description names a specific verb and resource ('Returns Legistar meetings, agenda items, votes and documents for any city on Legistar') and adds a framing question ('What did a city council decide?'). The domain is narrow enough that no sibling scraper (grants, tenders, awards, notices) could be confused with it.

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?

An explicit 'When to use' section gives the condition ('city council or county board meetings, agenda items, votes and documents from a Legistar client') and even example client slugs. It stops short of naming exclusions or alternative tools for closely related municipal-data needs, so it is clear context rather than full 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 already declare readOnly, openWorld and non-destructive, so the safety profile is covered; the description still adds genuinely new context: the run executes the Apify Actor via the hosted MCP gateway, consumes the caller's own APIFY_TOKEN and Apify account quota, and returns run/dataset IDs used for paging. It does not flag cost/credit consumption or pagination mechanics explicitly, keeping it 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?

Front-loaded with the concrete question it answers, then labeled When to use / Returns / Behavior sections that are easy to scan. The opening phrase repeats the title verbatim and the When-to-use line largely restates the first sentence, which is mild waste.

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 Returns section carries the burden and does so adequately (one JSON row per result plus run/dataset IDs for paging), and the Behavior section explains execution and account context. Slight gap: the framing question asks about tenders 'published today' while the actual filters are updatedFrom (default 7 days) / updatedTo, so an agent could mis-set the time window.

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 each parameter self-documented (cpv prefix match, case-insensitive keyword match, maxItems cap, ISO datetimes with defaults), so the baseline is 3. The description adds only field names in the returns line and nothing about how cpv, keywords or noticeType stages behave 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?

States a specific resource (UK government tenders) with the two exact sources named (Find a Tender and Contracts Finder), plus the fields returned (buyer, value, deadline, source link). This source-and-jurisdiction specificity is enough to separate it from the EU TED and USASpending/govcon siblings without opening any 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?

A dedicated 'When to use' line gives clear positive context (UK public-sector tenders with buyer, value and deadline). It stops short of explicit exclusions, e.g. it never says 'for EU notices use eu-ted-notices-scraper instead', so an agent must infer the boundary from geography.

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, non-destructive, open-world behavior, so the bar is lower, yet the description still adds real operational context: it starts one run of the Apify Actor via the hosted MCP gateway, requires the caller's own APIFY_TOKEN, and bills against their Apify account. It also discloses that results come back as dataset rows plus run/dataset IDs for paging, and links the source docs.

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?

Well structured and front-loaded: a summary sentence, then labeled 'When to use', 'Returns', 'Behavior', and 'Docs' sections. There is minor redundancy, since 'federal contract and grant awards' is repeated in the title and the first sentence, but nothing is wasted overall.

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 10-parameter, zero-required scraper with no output schema, the description covers the essential gaps: what the run produces, that rows map one-per-result, and how to page the full dataset via run/dataset IDs. It does not touch on cost/credit consumption or run duration, which are the remaining unknowns for an agent invoking a paid Actor run.

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 every parameter is already documented in the schema, which sets the baseline at 3. The description only restates the same dimensions ('by agency, recipient, NAICS and period') and adds no syntax, precedence, or interaction guidance (for example how keywords interact with agency/recipient filters) 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?

States a specific verb and resource: 'Pulls USAspending awards by agency, recipient, NAICS and period, with award IDs and source links.' The domain (USAspending federal awards) is concrete enough to separate it from the tender/meeting siblings, though it never explicitly contrasts itself with publicrecords--grants-gov-scraper, which covers adjacent grant data.

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?

A dedicated 'When to use' block gives a clear trigger: 'when you need who won US federal contracts and grants and for how much... by agency, recipient, NAICS or period.' It gives positive context but no exclusions or named alternatives for the overlapping siblings, so it stops short of full routing guidance.

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