NextBid — Government Bids for AI

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

With no annotations, the description carries the full burden and does disclose real behavioral context: counts are distinct with duplicates excluded, each set-aside counts once, open competition is excluded, and 'replica_as_of'/'as_of' reveal the data is served from a replica. It does not explicitly confirm read-only/no-side-effects, but the counting semantics are substantive.

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 essentially one long run-on sentence with deeply nested parentheticals, which is hard to parse even though most tokens are informative. Content is not padded, but the structure is poor and would benefit from field-level formatting.

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 and defines each returned field, effectively standing in for return-value documentation. The main gap is the absence of usage context (when to call this vs. sibling search/list tools).

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing to disambiguate. The description instead documents the return fields, which is outside the parameter schema but adds useful meaning.

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

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

The description clearly establishes the resource: aggregate corpus numbers/statistics (solicitations, set-asides, documents, timestamps). The verb is implicit ('provides/reports') rather than explicit, but an agent can tell this is the aggregate-stats tool, distinct in kind from the list_/get_ siblings. No explicit sibling differentiation is offered, which holds it below 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?

There is no when-to-use guidance, no mention of when not to use it, and no routing to alternatives like search_opportunities or list_set_asides. The description only explains output fields, leaving the agent to infer that this is a read-only aggregate view.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the link is time-limited, only one stored original is served, a single request is made, and the file comes from NextBid's object store rather than through the API. It does not mention auth requirements or what happens on expiry/invalid sha.

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 dense sentences with the core capability front-loaded followed by the delivery mechanism and constraint; no filler clauses.

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 2-param, no-annotation, no-output-schema tool, the description covers what the return value is (a link), its lifetime, and where the bytes come from. Remaining gaps (auth, failure modes, expiry duration) are minor but real.

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%, so the description must compensate, and it does for sha256 by tying it to list_documents with stored=true — real meaning beyond the regex pattern. nb_id is only implied via 'of an opportunity', so it is not fully documented.

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

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

Specific verb+resource: returns a time-limited download link for one stored original document. It implicitly distinguishes itself from siblings like get_document_text (text extraction) and list_documents (enumerating), though it never names them.

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 a prerequisite ('sha256 from list_documents, where stored is true'), which implies when this tool is applicable. However, it never states when to prefer this over get_document_text or what to do if the document is not stored, leaving routing 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?

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior beyond the schema: text is 'verified against its indexed hash' (implying possible verification failure) and 'One request' hints at single-shot retrieval with no pagination. It omits what happens on hash mismatch, any rate limits, or how max_chars truncation behaves.

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 tight sentences with no filler; the identity rule for sha256 and the offset linkage are front-loaded before the 'One request' note. Slightly cryptic phrasing ('AnyDoc', 'One request') costs it the top mark rather than any verbosity.

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

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

The description covers the core contract for a 3-param read tool with no annotations and no output schema: it says the return is the document's extracted text and how the sha256 is resolved. It leaves max_chars and nb_id semantics unaddressed, which is a real gap given zero schema coverage.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for sha256 (either the text sha256 or the original sha256 from get_evidence), but nb_id and especially max_chars are left completely undefined, including whether max_chars truncates or errors.

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 verb+resource ('extracted text of one document') and pins the sha256 identity to the get_evidence flow, which distinguishes it from get_document_download at a high level. It does not explicitly contrast itself with the sibling download tool, and 'AnyDoc' is jargon an agent may not resolve, but the retrieve-text purpose is unambiguous.

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

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

Implies usage context by tying sha256 to 'the original sha256 from get_evidence' and stating offsets from get_evidence index into this text, which routes the agent in the right sequence. However, there is no explicit when-to-use vs get_document_download or when-not guidance, so the caller must infer the distinction.

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

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

With no annotations, the description carries the full burden, and it does add real behavioral semantics: it defines what a RESOLVED verification means (offsets match hash-verified text and the graph quote) and states that gaps such as pending custody and unresolved citations are surfaced rather than hidden. However, it says nothing about auth requirements, error/not-found behavior, or how the claims_limit/claims_offset pagination behaves despite those parameters existing.

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 front-loaded with the resource, but the bulk arrives as one long run-on sentence stuffed with parentheticals that is hard to parse. 'One request' is cryptic and does not clearly earn its place. Dense but not well-structured.

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

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

With no output schema, the description rightly spends its words on the return shape, and that coverage is genuinely good. But for a tool with zero annotation coverage, 0% schema coverage and paginated parameters, the missing parameter semantics, pagination behavior, and routing guidance leave the definition materially incomplete.

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 there are 3 parameters, so the description needed to compensate and largely does not. 'One opportunity' loosely implies nb_id targets a single record, but claims_limit and claims_offset are never mentioned, so pagination semantics are documented nowhere. None of the three parameters is explained.

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 makes it clear this fetches the evidentiary bundle for a single opportunity, and the enumeration of documents plus Graphify claims pins down the resource precisely. It never states an explicit verb ('returns'/'fetches'), but an agent can tell it is a read-style retrieval of aggregated evidence. It does not contrast itself against siblings like get_opportunity or get_document_text.

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 or when-not-to-use guidance and no named alternative; an agent cannot learn from the text when get_evidence beats several targeted calls to get_document_text/get_document_download/list_documents. The trailing 'One request' hints at batching efficiency but is too terse to count as routing guidance. No prerequisites or context conditions are 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?

With no annotations, the description carries the full behavioral burden, and it does disclose one genuinely non-obvious trait: 'counts as a delivered solicitation the first time this account receives it,' which warns the agent about a metered side effect. It is silent on auth/permission needs, error behavior for a malformed or unknown id, and whether repeat fetches are free, so it is partial rather than complete.

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

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

Two sentences, front-loaded with the core action and key, with the payload list and billing caveat following. The field enumeration is dense and slightly crammed into the first sentence, but every clause carries information and nothing is padded.

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

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

For a single-parameter read tool with no output schema, the description usefully enumerates the returned contents, standing in for the missing return documentation, and flags the billing side effect. The remaining gap is the absence of any routing versus sibling tools, which a complex 13-tool surface would benefit from.

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

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

Schema description coverage is 0%, so the description must compensate for the single nb_id parameter. It does identify the identifier domain ('NextBid id') and repeats the NB######## shape, but that format is already encoded in the schema pattern and the description does not say where an id comes from or what happens if it is unknown — partial compensation only.

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

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

The description names a specific verb and resource ('Full record for one opportunity') and pins the key ('NextBid id (NB########)'), then enumerates the payload (description, AI summary, buyer contacts, amendments, filed documents). That enumeration implicitly separates it from per-artifact siblings like list_documents and get_document_text, but it never explicitly states the relationship, 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?

There is no when-to-use or when-not-to-use guidance. The description never references search_opportunities (to find an id) or the document-level siblings (once you already have the record), and does not state prerequisites such as requiring a previously discovered NextBid id. The billing sentence is a cost note, not usage 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?

With no annotations, the description carries the behavioral burden and does so meaningfully: it discloses that pipeline artifacts are counted but not listed, that only names and metadata (not contents) are returned, and that nextbid_documents text is fetched via read_file. These scoping constraints are real behavioral context. It omits anything about auth, pagination, or size 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?

It is a single front-loaded sentence, but it is packed with nested parentheticals that make it harder to parse quickly. The return-structure detail earns its place, yet the phrasing could be tightened into a cleaner list of what is included versus excluded.

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 annotations, the description does the work of describing the return shape (two document groups, their fields, what is excluded). An agent knows what it will receive and how to act on it. The main missing piece is guidance on the nb_id value itself.

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% for the single nb_id parameter, so the description must compensate. It does add that the id scopes to 'one opportunity', but it never explains the id's shape, source, or how to obtain it (the ^NB\d{8}$ pattern lives only in the schema). Partially compensating, not fully.

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 document set for one opportunity) and enumerates exactly what is returned: source_documents with their metadata fields and nextbid_documents. It implicitly distinguishes itself from reading tools by noting content is readable via read_file and that this returns 'names and metadata only'. It is clear, though no explicit verb like 'list' anchors the opening.

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 framing: use this to see what documents exist for an opportunity, then read_file for the normalized text. It routes to one sibling (read_file), but gives no explicit when-to-use/when-not guidance and does not differentiate from get_document_text or list_files, which could easily be confused with 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?

No annotations are supplied, so the description carries the full disclosure burden. It usefully reveals the default vs expanded result set and the internal version/class semantics, but says nothing about permissions, result size, ordering, or whether the listing is paginated.

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 dense sentences, front-loaded with what is returned, then the include semantics, then the retrieval alternative. Some parenthetical jargon makes it terse, but no sentence 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?

With no annotations and no output schema, the description does the heavy lifting reasonably well: it names the returned content classes, explains how include expands the set, and routes to read_file for content. It stops short of describing the response shape or pagination, but covers what an agent needs to choose and call the 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 compensate. It explains include='all' well (adds artifacts and superseded generations), but nb_id is only implied by 'one opportunity' and its NB\d{8} pattern is never clarified in the 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?

The description states what is listed and for what scope: 'the current stored documents for one opportunity', with the concrete content classes ('Document 0 markdown/json and normalized attachment markdown'). It clearly distinguishes itself from read_file ('Use read_file to fetch one'), but does not differentiate itself from the sibling list_documents, leaving some ambiguity between the two listing tools.

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

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

It explains the mode switch ('include="all" adds pipeline artifacts ... and superseded Document 0 generations') and names the alternative for retrieval ('Use read_file to fetch one'). It gives clear context for use but offers no explicit guidance on when to prefer this over the sibling list_documents.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses that counts are 'today's', distinguishes open_designated (source-marked) from open_mentioned (title-language only), and warns 'Never an eligibility determination' — an important scope boundary. It does not cover caching/pagination behavior, but for a read-only reference list this is rich context.

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 resource and the authoritative action ('Use an id or alias in search_opportunities.set_asides') placed after the field list. The opening sentence is a dense run-on enumerating fields, but every clause carries information and nothing is redundant.

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?

No output schema exists, so the description must explain return values — and it does, listing fields and clarifying the count split and alias semantics. Combined with the cross-reference and the eligibility disclaimer, an agent has everything needed to call and interpret this 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?

Zero parameters, so the schema offers nothing to document and the baseline is 4. The description goes further by explaining what each returned field means (level, aliases, the two count buckets), adding semantic value even though there are no inputs.

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 exact resource (set-aside/small-business programs NextBid recognizes), enumerates the fields returned (id, name, level, aliases, counts), and explicitly separates this tool from search_opportunities, where the returned ids/aliases are consumed. An agent can tell precisely what this tool yields and how it differs from its 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?

It gives concrete downstream usage — 'Use an id or alias in search_opportunities.set_asides' — which implies the tool is a reference lookup to run before filtering. It stops short of stating when-not to use it (e.g. vs. get_opportunity or corpus_stats), so it is strong but not fully explicit about selection.

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?

No annotations exist, so the description bears the full burden. It usefully discloses the return shape and adds a semantic caveat ('Specialties describe supported categories, not open bids') that prevents misreading the data, but says nothing about ordering, size, caching, or rate limits for what could be a large catalog.

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

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

Three short sentences, front-loaded with what the tool returns, then the follow-up usage hint, then the one-line caveat. Every sentence carries distinct information with no repetition of the name or title.

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

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

With no parameters and no output schema, the description must carry the return contract, and it does enumerate the fields and the daily count. It is nearly complete; only secondary details like ordering or catalog size 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description concerns itself entirely with output content rather than parameters, which is appropriate here.

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 the resource (the trade catalog) and enumerates the per-entry fields (id, name, description, specialties, search aliases) plus today's open count, so an agent knows exactly what this returns. It distinguishes itself from the sibling search_opportunities by positioning itself as the id/alias source that feeds it, though the verb is implied by 'catalog' 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?

It gives a concrete downstream instruction ('Use an id or any alias in search_opportunities'), which implies this is a lookup-first tool, but it never states when to call this versus list_documents, list_set_asides, or corpus_stats, nor any exclusion. Usage is inferable rather than explicit.

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

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

With no annotations, the description carries the full burden. It adds useful context — the customer-stated precondition, the read-vs-pursuit distinction, and 'Free' (no cost) — but says nothing about whether an existing status is overwritten, what permissions are needed, or what the call returns.

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

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

Three short sentences, front-loaded with the action, followed by the guardrail and cost. No filler; 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?

Purpose, trigger condition, and cost are covered, but for a mutation tool with no annotations, no output schema, and 0% parameter documentation, the definition leaves the agent guessing about the note parameter and the effect of re-recording a 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?

Schema description coverage is 0% across 3 parameters, so the description must compensate. It does add meaning to status by framing the values as customer engagement states, but nb_id (the NB###### identifier) and especially note (max 500 chars) get no explanation anywhere.

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 (record) and resource (an opportunity's engagement state), enumerating the six statuses it can record. An agent can distinguish it from read-only siblings like get_opportunity and search_opportunities without opening the schema.

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

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

Gives an explicit precondition ('Call it only when the customer says so') and an explicit exclusion ('reading a bid is never a pursuit'), which is exactly the when-not guidance needed for a status-tracking write.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely behavioral fact: the call is 'Free,' i.e. it does not consume allowance — directly relevant since the payload itself explains what counts as a call. It says nothing about auth requirements, rate limits, or whether the response is user- or workspace-scoped, which keeps this at a middling score.

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

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

One compact sentence with the resource name front-loaded and no filler. The dense noun-list is unusual but every item earns its place by declaring a returned field.

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 sensibly compensates by listing the returned fields, which is close to complete for a zero-parameter read of the caller's own account. The remaining gap is routing — it never says how this differs from my_usage, leaving sibling ambiguity unresolved.

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 per the rubric the baseline is 4. The description adds value by enumerating the fields the parameterless response contains rather than leaving the agent to infer them.

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 enumerates exactly what the tool surfaces — plan, allowance used/remaining, reset or trial expiry, keys, call definition, upgrade path, business profile — so an agent can tell it returns account/billing metadata. The verb is implied rather than stated ('The account's meter'), and it never names or distinguishes itself from the sibling my_usage, which likely covers overlapping usage 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?

There is no when-to-use guidance at all: no trigger conditions, no prerequisites, and no mention of the obviously adjacent sibling my_usage. The agent has to guess whether to call this or my_usage for account/quota questions.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the return contents (usage meters plus plan/trial expiry) and that the call is free, but says nothing about authentication, rate limits, or whether the numbers are live versus cached.

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 front-loads the resource and lists the returned meters without filler; the trailing 'Free' fragment is terse but adds a genuinely useful signal. No wasted sentences.

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 must convey what comes back, and it does by enumerating the meters and plan/trial expiry. For a zero-parameter read tool this is nearly complete, missing only auth/refresh context.

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 to explain; baseline 4 applies. The schema confirms an empty object with nothing to misinterpret.

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 (the account's meters) and enumerates what it reports: requests used/remaining, solicitations delivered/remaining, plan period or trial expiry. It is clearly distinguishable from list/search siblings, though it does not explicitly contrast with my_account or corpus_stats.

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 alternatives such as my_account. The single word 'Free' hints at cost but does not tell the agent when this tool is the right choice.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses truncation behavior and the default character budget, which an agent could not infer otherwise. It omits anything about permissions, missing-path errors, or what happens when the artifact exceeds max_chars, so the disclosure is partial.

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 the action and target front-loaded; the parenthetical and truncation clause each earn their place. Slightly dense but no wasted wording or filler.

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

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

For a simple 3-parameter read tool with no output schema and no annotations, the description covers the core action, the path source, and truncation. It still leaves the artifact-type boundary against sibling readers and failure behavior unaddressed, so it is adequate rather than 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 0%, so the description must compensate. It explains 'path' (via its origin in list_files) and gives max_chars a default value (60,000) not present in the schema, which adds real meaning. However, nb_id is never explained and no parameter format or boundary semantics are given beyond the schema's own constraints.

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: reading one stored text artifact belonging to an opportunity, with the path source parenthetically identified. It clearly separates from list_files, but does not distinguish itself from similar sibling readers like get_document_text or get_evidence, leaving the agent to guess which artifact type this targets.

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 parenthetical '(path from list_files)' implies the workflow prerequisite of listing files before reading one, which is genuinely useful. However, there is no guidance on when to prefer this over get_document_text/get_evidence, nor any exclusion for artifact types this tool does not handle.

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

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

With no annotations, the description carries the full burden and does it well: it discloses two metering dimensions (per request and per first-seen solicitation, repeats free), trial vs paid caps, the 400 on exceeding plan max, and mid-page truncation semantics via delivery.truncated and delivery.withheld. These are exactly the operational traits an agent cannot get from the schema.

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 what-and-where, then returns, then metering, then edge cases. Dense but nearly every sentence earns its place given 16 parameters and no annotations; only the metering paragraph runs long enough to risk being skimmed.

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 16-parameter tool with no output schema and no annotations, it covers return shape (agency, deadline, codes, document status, source link, total, facets) and failure modes at page boundaries. It stops short of clarifying how results hand off to get_opportunity or the document siblings, which is the main remaining gap.

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 88%, so the schema already carries most parameter meaning and baseline is 3. The description still adds value on top: page_size 0 = counts/facets only, trial max 25 vs paid max 100 with a 400 above the plan cap, and the fact that specialties never filter but only re-rank.

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

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

Specific verb+resource: 'Search open government solicitations ... in NextBid's normalized corpus,' with the source list and the shape of the returned record spelled out. It clearly reads as the search entry point, but it never names or contrasts a sibling such as get_opportunity (single fetch) or corpus_stats, so an agent must infer the boundary itself.

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: defaults (open=true), the page_size 0 shortcut for counts/facets, and cross-references to list_set_asides and list_tradelines for valid parameter values. There is no explicit when-to-use-this-vs-get_opportunity guidance and no exclusions, which leaves real routing ambiguous.

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