askTender

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the substance of the answer (trade agreements, foreign-bidder rules, registrations needed), which tells the agent what the result will contain. It does not mention latency, caching, or coverage caveats.

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, both front-loaded: the first defines the answer, the second defines the invocation condition and inputs. No filler or redundant restatement of 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?

There is no output schema, so the description has to convey what comes back; it does so by listing the factors the answer weighs (trade agreements, foreign-bidder rules, registrations). Combined with full schema coverage and read-only annotations, an agent has enough to call it correctly, though the response shape (boolean vs. explained verdict) is not stated.

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 three parameters, including the 'not needed if tender_id is given' relationship. The description's 'Give a tender_id or the tender's country' merely restates that either/or semantics without adding format or precedence detail. Baseline 3 is appropriate.

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

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

The description states a precise question the tool answers ('Whether a company based in one country may bid for public tenders in another country') and enumerates the considerations involved (trade agreements, foreign-bidder rules, registrations needed). The cross-border framing clearly separates it from the sibling check_my_eligibility, which concerns the user's own eligibility.

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 an explicit trigger: 'Use when the user asks whether a company from one country can bid on, or take part in, public tenders in another country.' It also tells the caller what input to supply ('Give a tender_id or the tender's country'). It stops short of naming alternatives or stating when not to use it versus check_my_eligibility or get_requirements.

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, non-destructive, closed-world), so the bar is lower. The description adds real context beyond them: it discloses an authentication prerequisite ('Needs the askTender account connected') and outlines the returned assessment (requirements met, gaps, remediation). It stops short of stating error behavior when the account is not connected.

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 with essentially no waste; the capability statement is front-loaded and the usage trigger follows. There is mild redundancy between 'can bid on a tender and qualifies' and the later 'qualifies for, or can bid on'.

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 what is returned (which requirements are met, what is missing, how to close each gap) and flags the account prerequisite. The one material omission is disambiguation from the sibling can_company_bid, given only one fully documented input parameter otherwise.

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?

Only one parameter, tender_id, and schema description coverage is 100%, so the schema already carries the semantics. The description adds no format or constraint detail beyond 'a specific askTender tender,' which is the expected baseline when the schema 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 and resource: assessing the user's own company against a given tender and reporting which requirements are met, which are missing, and how to close gaps. It clearly scopes to the user's own askTender-account company. However, it never distinguishes itself from the near-identical sibling can_company_bid, leaving the agent to guess which one to select.

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 trigger: 'Use when the user asks whether their own company qualifies for, or can bid on, a specific askTender tender.' The 'own company' phrasing hints at a contrast with can_company_bid, but no alternative or exclusion is actually named, so the boundary between the two tools is left to inference.

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, destructiveHint=false, and openWorldHint=false, so the safety and locality profile is covered. The description adds that this is an informational comparison of plan features and fit but says nothing about whether the data is static, cached, or how it interacts with the user's actual account.

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 resource and its contents, then the usage trigger. There is minor redundancy between the listed contents ("who each is for") and the usage clause ("which plan to choose"), but nothing is wasted at length.

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

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

For a read-only informational lookup with one optional parameter and no output schema, the description is sufficient: an agent knows what data it returns and when to invoke it. The only soft gap is that it neither describes return structure nor clarifies the boundary with my_account.

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% for the single optional 'situation' parameter, and its schema description already supplies concrete examples. The description alludes to the parameter indirectly ("which fits the user's situation") but adds no format or constraint detail 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?

The description states a specific resource (askTender's Pro, Intelligence, and Business plans) and enumerates the content covered: prices, inclusions, target audience, and fit. No sibling tool covers plan/pricing comparison, so it is functionally distinct, though it doesn't name a sibling to contrast against.

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 explicit triggers: "Use when the user asks about pricing, which plan to choose, or what askTender can do for them." That is clear when-to-use guidance, but it names no alternative tool or exclusion conditions (e.g., account-specific plan details belonging to my_account).

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description goes beyond that by stating the return shape ('titles, summaries and links'), which the annotations do not convey, though it says nothing further about result limits or freshness.

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?

One compact sentence with a parenthetical topic list plus a short return-value clause; the resource being described leads and the parentheses are the only slightly bulky part. Nothing is wasted, though the example list could be trimmed.

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 only two fully-documented parameters and no output schema, the definition covers what the tool returns (titles, summaries, links) and what it is about. The one remaining gap for an agent is knowing how many guides come back or whether results are ranked, which the description does not address.

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% — both 'query' and 'country' are documented with examples in the schema itself. The description adds no syntax or formatting guidance for either parameter, 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?

The description names a specific resource (askTender's procurement guides) and enumerates the topic coverage (portal registration, digital signatures, bid security, foreign bidders, consortiums), so an agent can tell it is a knowledge-lookup tool rather than a tender-search tool. It does not explicitly contrast itself with siblings like get_requirements or search_tenders, which keeps it at 4 rather than 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 topic list — an agent can infer this is for 'how does procurement work' questions — but there is no explicit when-to-use statement, no when-not-to-use, and no named alternative. For a niche lookup tool the intent is reasonably inferable, so this is minimum-viable rather than a gap-free 4.

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 this is a safe, closed-world read (readOnlyHint=true, openWorldHint=false, destructiveHint=false), so the bar is lower. The description adds genuinely non-structural context: the subscription tier requirement and the fact that some checklist items are drafts askTender prepares for signature, which signals downstream actions the agent should be aware of.

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 resource and its contents, with the eligibility constraint appended without padding. No redundant restatement of the title or name.

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, single-parameter tool with no output schema and annotations covering safety, the description conveys the shape of the return value (three checklist categories) well. The gaps are the undocumented tender_id and the absence of any note on list size or ordering.

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 0% for the single tender_id parameter, and the description does not define its format, provenance, or whether it is required. It only implies the input is 'a tender,' so an agent cannot tell from the description alone where to source the identifier.

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 and scope: a per-tender submission checklist personalized to the user's company, broken into three concrete categories (already-held documents, askTender-prepared drafts, items to obtain with lead times). It is readily distinguishable from generic siblings like get_requirements or can_company_bid, though it never names an alternative to sharpen the contrast.

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 supplies one real gating rule ('Pro plan and above'), which is useful eligibility guidance, and the phrase 'for a tender' implies it is used after a tender is identified. However, it never states when to prefer this over get_requirements or can_company_bid, nor any exclusion or timing 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 readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavioral context beyond that: the tool is gated to Pro plan and above, which is an entitlement/auth constraint not available in structured fields. It stops short of describing pagination or volume, which is why it is 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?

A single dense sentence with zero filler, front-loaded on what is returned and ending with the plan constraint. Every clause (content scope, 'in the tender's own words', routing, plan gate) 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?

With no output schema, the description usefully sketches the return payload (requirement categories, verbatim text, and routing to an owner) plus the entitlement gate, which is sufficient for an agent to call it. It omits any mention of input source for tender_id or behavior when the tender does not exist, keeping it out of 5 territory.

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 the single tender_id parameter carries no description in either place, so the description 'must compensate' and does not — it never explains what tender_id refers to or its expected source (e.g., from search_tenders/get_tender). The name is self-evident enough that this is not fatal, so a baseline-adjacent 3 is fair.

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 ('Every requirement of a tender') and enumerates the content categories covered (financial, experience, certifications, registrations, bid security, documents), so an agent knows exactly what it returns. It does not explicitly contrast itself with siblings like get_tender or get_bid_kit, which likely also touch tender detail, so differentiation must be inferred.

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 'Pro plan and above' note is a real eligibility gate the agent must respect before calling. However, there is no statement of when to prefer this over get_tender or get_bid_kit, so usage against alternatives is only implied by the phrase 'Every requirement'.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context by enumerating the returned payload (title, buyer, country, deadline, value, status, brief, link) — important since no output schema exists — and notes the brief is only present 'where available'.

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 identifies the resource and key before listing fields. The field enumeration is long but each item carries information, so little 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 tool with no output schema, enumerating the return fields covers the main gap. Only missing piece is failure behavior for an unknown or stale tender_id, which is minor here.

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% and the single parameter's description already explains its origin (search_tenders or an askTender link). The description's 'by its askTender id' restates the schema rather than adding format or constraint detail, 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+resource ('the facts of one tender') and pins down the lookup key (askTender id), then enumerates returned fields. It reads clearly as the singular counterpart to search_tenders, though it never names a 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: 'by its askTender id' plus the schema note that the id comes from search_tenders or a link. There is no explicit when-to-use vs when-not statement or warning about passing an unknown id.

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, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds no behavior beyond that — no note on whether the plan reflects live subscription state, caching, or permission requirements, and 'what it includes' is left undefined.

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 short sentence, front-loaded with the resource, with no filler or redundancy. Its brevity is appropriate in form, though the one sentence is thin rather than dense.

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 and no parameters, the description carries the full burden of explaining what comes back, and 'what it includes' does not say. An agent cannot tell whether it receives a plan name, tier, feature list, or billing status.

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 no parameter semantics for the description to carry. Baseline 4 applies; the description cannot be faulted for omitting parameter detail that does not 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 identifies the resource (the user's askTender plan) but supplies no verb and largely restates the title 'My askTender plan'. Sibling tools such as compare_plans and check_my_eligibility make the boundary inferable, but the description itself does not sharpen 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?

There is no statement of when to call this versus alternatives. Nothing tells the agent how this differs from compare_plans or other my_* tools, so routing must be inferred from the tool name alone.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered elsewhere. The description adds modest scope information (bids under preparation with askTender, and that status is part of the result), but says nothing about result size, filtering scope (active only vs. all time), or ordering.

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 short sentence with no filler, and the core noun is front-loaded. It is a fragment rather than a complete statement, which slightly undercuts structure.

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-param browse tool with no output schema, the description should tell the agent what set is returned and how it differs from the other 'my_*' listers. It leaves the agent unsure whether this returns in-progress managed bids, historical bids, or status records, which is exactly the information needed to select 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?

The tool takes zero parameters, so the baseline of 4 applies and the schema has no parameter documentation burden. The description neither misleads about inputs nor needs to compensate for any schema gap.

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 identifies the resource (the user's bids being prepared via askTender) and mentions status, but it reads as a noun phrase rather than a verb+resource statement of what the tool does (list/return). With three near-identical siblings (my_saved_tenders, my_matching_tenders, my_watchlist) no differentiation is offered, leaving the agent to infer that 'bids' here means managed bids in progress.

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 mention of alternative tools. Given a sibling set full of overlapping 'my_*' listing tools, the absence of any routing hint is a real gap.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds the useful mechanic that matching is driven by the stored company profile rather than only keywords, but says nothing about result ordering, pagination, or what 'open' excludes.

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 what the tool returns and how matching works, then the usage cue. The colon-plus-value construction is slightly dense but every clause 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 simple two-param read tool this is close to adequate, but with no output schema the description should hint at the return shape (list of tenders, ordering, how many) and it does not. The limit/pagination story is likewise absent.

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 0% and the description clarifies only `query` ('a search phrase if given'), correctly signalling it is optional. The `limit` parameter (default 8, max 10) is never mentioned, so roughly half the parameters remain undocumented in both places.

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 specific resource (open tenders for the user's company) and the mechanism that produces them (the askTender profile's stated capabilities, or a search phrase). This distinguishes it conceptually from the generic search_tenders, though it 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?

Gives a clear trigger: 'Use when the user asks which tenders suit or match their company.' It states the context positively but offers no exclusions or explicit alternative (e.g. 'use search_tenders for keyword discovery across all companies'), so the agent must infer the boundary.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only that deadlines are included in the results, with no mention of ordering, pagination, or whether saved items are user-scoped.

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 short sentence with no filler that is front-loaded on the resource. It is economical, though arguably under-specified rather than maximally 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 zero-argument list tool with no output schema, the description should at least say what the list contains and how it is scoped. 'With deadlines' is the only added detail, leaving the return contents and distinction from sibling list tools implied.

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 schema carries the full burden and no parameter semantics are needed from the description. Baseline 4 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 the resource (tenders the user has saved on askTender) and hints at the returned field ('with deadlines'), but it is a noun phrase with no verb and does not distinguish this from close siblings like my_watchlist, my_matching_tenders, or my_bids.

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?

No when-to-use guidance is given. With siblings such as my_matching_tenders, my_watchlist, and my_bids in the same family, the agent gets no signal about which of these to call for a given user intent.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the entitlement requirement (plan tier) and the scope of returned entities and their recency, which is exactly the kind of context annotations cannot express; it omits pagination or result-size 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?

Two short sentences with no filler: content first, then eligibility constraint. It is tightly front-loaded and every clause carries information, though 'Intelligence plan and above' is terse enough to be slightly ambiguous about the exact tier name.

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 tool with no output schema, the description supplies the entity types, the recency dimension, and the plan gate. It lacks any indication of return shape or volume, a minor gap given annotations cover the safety and openness profile.

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 and 100% schema coverage of an empty object, so the schema cannot be improved upon. The baseline of 4 applies because there is nothing parameter-wise for the description to clarify.

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 the resource (the buyers and competitors the user watches) and the value it returns (their recent activity), which is more specific than the bare tool name. It does not explicitly differentiate itself from the sibling `watch` tool, leaving the agent to infer that this is the read side of that pair.

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 an eligibility precondition ('Intelligence plan and above'), which is genuinely useful gating information. However, it offers no guidance on when to choose this over related siblings such as `watch`, `my_saved_tenders`, or `my_bids`.

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=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive local write. The description adds the effect context (the saved item drives deadline reminders and tracking), which is useful, but it says nothing about idempotency, duplicate handling, or authentication requirements.

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 sentence with the action front-loaded and the clarifying parenthetical trailing it. Every clause earns its place and there is no padding.

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, non-destructive save tool with annotations covering the safety profile and no output schema, the description is nearly sufficient. The only real gap is routing relative to the watch/watchlist siblings, which an agent would need in order to pick the right 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?

Schema description coverage is 0%, so the description must carry the parameter burden, and it does not mention tender_id at all. The single parameter is self-explanatory by name and type (integer), which keeps this at an acceptable baseline, but no format, source, or validity guidance is offered.

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 ('Save a tender') and adds the destination list and its purpose (deadline reminders and tracking), which goes beyond the title. It does not, however, distinguish itself from closely related siblings such as watch, my_watchlist, or my_saved_tenders, so an agent can't tell from the text alone which of these persistence mechanisms applies.

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?

No when-to-use or when-not-to-use guidance is given. With siblings like watch, my_watchlist, and my_saved_tenders in the set, the description should say how 'saving' differs from 'watching' and when to prefer one over the other; it leaves that entirely to inference.

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 the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds real behavioral context beyond that: result cap ('up to 10 live tenders'), freshness ('refreshed daily'), source ('official procurement portals'), and returned fields (buyer, deadline, value, askTender link).

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 purpose, then return shape, then trigger condition. Every clause carries information (cap, freshness, source, fields, use case) with no filler 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?

With no output schema, the description usefully covers what comes back (buyer, deadline, value, link) and the 10-result ceiling, which is the key expectation-setting detail. Minor gaps remain: no mention of what an empty result set looks like or whether results are ranked, but nothing essential to correct invocation 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 coverage is 75% and the query/country/closing_within_days params are already well described in the schema. The description's 'by what is being bought and, optionally, the country' and 'up to 10' merely restate what the schema declares, adding no syntax, format, or edge-case detail (e.g. multi-country input, behavior when no results match).

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 ('Find open government tenders (calls for bids)') plus the primary scope ('by what is being bought and, optionally, the country'). An agent can distinguish this public-tender search from siblings like my_saved_tenders, my_matching_tenders, and the single-item get_tender, 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?

Explicit trigger sentence: 'Use when the user asks to find tenders, calls for bids or public contracts to bid on.' It gives a clear when-to-use but offers no when-not-to-use guidance or named alternatives (e.g. use get_tender for a known ID, my_matching_tenders for personalized results).

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the agent knows this mutates state without being destructive. The description adds useful context that the desk works 'with the user' and coordinates third-party Partners for certificates and filing, but omits cost, commitment, reversibility, and what happens after invocation.

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 first sentence is front-loaded and dense with relevant detail, but the dangling fragment 'Business plan.' does not earn its place and reads as an unexplained artifact. Slightly overlong for the amount of actionable information conveyed.

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 that initiates a multi-party managed service with no output schema, the description should clarify outcome, cost, or next steps; it only sketches the process. It is adequate to recognize the tool's role but incomplete for confident 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?

The single parameter tender_id has 0% schema description coverage, so the description must carry that burden and does not — it never explains that tender_id identifies the tender being handed over or how to obtain it. The description adds no meaning beyond the schema's field name.

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 concrete action ('Hand a tender to the askTender Desk') and explains the service the desk performs, which distinguishes it from siblings like get_bid_kit or save_tender. The trailing fragment 'Business plan.' is confusing and muddies an otherwise clear statement of 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?

There is no guidance on when to use this versus alternatives such as get_bid_kit, can_company_bid, or check_my_eligibility, nor any stated prerequisites (eligibility, saved tender, account state). The agent must infer the appropriate context entirely.

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 (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds genuinely non-redundant behavior: an entitlement constraint ('Intelligence plan and above') and a concrete enumeration of what is returned (winner, value, date, price guide). It does not disclose fallback behavior when no past contracts exist, which keeps it 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?

A single sentence that front-loads the primary payload (who won) and appends the use case and plan gate last. Dense parenthetical asides are readable, though the trailing 'Intelligence plan and above' and 'useful when...' clauses are tacked on rather than integrated.

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 correctly spends its words describing the return contents and the access tier required. For a one-param read-only tool this is close to complete; only empty-result handling and output format detail are absent.

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 carry the burden, but 'For a tender' only loosely implies that tender_id identifies the tender being investigated. With a single self-evidently named integer param, the gap is minor, but no format, type, or lookup semantics are added 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 names a very specific resource and output set: the incumbent/last winner for a tender, the buyer's closest past contracts (winner, value, date), and a price guide. No sibling tool (my_bids, search_tenders, get_tender) covers this, so it is distinguishable. It loses a point only because the action verb is left implicit in a noun-heavy phrase rather than stated directly.

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 offers one situational cue — 'useful when the notice publishes no value' — which implies a context for calling it, but names no alternative tool and gives no explicit when-not guidance. The Intelligence-plan gating is a prerequisite rather than usage routing. Adequate but clearly incomplete compared to a tool that names its 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds a plan-tier authorization requirement not present in the structured fields, but says nothing about result size, ordering, or coverage 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 short sentences, zero waste. The core definition is front-loaded and the eligibility constraint is appended as a compact qualifier rather than buried in 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 zero-parameter, read-only list tool the description is close to sufficient, and the plan gate is an important addition. However, with no output schema, an agent gets no signal about what a renewal record contains (deadline, buyer, value) or how many results 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?

The tool takes zero parameters and the schema is an empty object, so there is no parameter semantics to document. The description correctly implies the scope is implicitly the calling user's markets, which is the only semantic an agent needs.

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 concrete resource and scope: contracts in the user's markets that end soon, with a parenthetical clarifying the renewal/tender framing. It is clearly distinct from sibling list tools like my_bids or my_saved_tenders, 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 only usage guidance is the eligibility gate ('Intelligence plan and above'), which is genuinely useful but is a prerequisite rather than a when-to-use rule. It never says when to prefer this over my_matching_tenders, my_watchlist, or search_tenders, so the agent must infer the trigger from the name alone.

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-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the safety profile is covered structurally. The description adds the plan gating constraint but says nothing about idempotency, duplicate handling, or side effects on the watchlist.

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 compact sentences with the action front-loaded, no filler. The trailing plan fragment is slightly abrupt but still informative rather than wasteful.

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 mutation tool with no output schema and 25% schema coverage, the definition covers the core action and eligibility but omits duplicate-handling behavior and return semantics. Adequate but with clear 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?

Schema coverage is only 25%, so the description must compensate, and it partially does by clarifying the 'kind' domain (buyer vs supplier/competitor). The name and country parameters receive no elaboration in either the description or schema, and tender_id is only explained by its schema description.

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 (add) and resource (public buyer or supplier) plus the outcome (follow their tenders and awards). It implicitly separates itself from save_tender and my_watchlist, but never names a sibling for contrast.

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 eligibility prerequisite 'Intelligence plan and above' is stated, which is genuinely useful, but there is no guidance on when to use this versus save_tender or my_watchlist, and no indication of what happens on repeat adds.

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