workspaceAlberta

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

Annotations already cover readOnly/openWorld/non-destructive, and the description adds genuinely new operational context: it is a hosted call requiring sign-in and an active subscription, and it names the underlying model. It does not mention latency, per-call cost/quotas, or how long an analysis is cached, which would be the remaining useful disclosures.

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 action and followed by the gating prerequisite. No filler, no restating 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?

For a read-only, non-destructive analysis tool with 100% schema coverage and no output schema, the description covers what the tool produces and what it requires to run. Minor gap: no hint of response length/format despite exposing a `max_tokens` control, and no guidance on the shared-public-endpoint vs subscriber-key modes for this specific call.

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

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

Schema description coverage is 100% and the required `reference` parameter plus the nested `profile` object are fully documented in the schema, including the override semantics of the inline profile. The description adds nothing about parameters beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (review/analyze), a specific resource (a CanadaBuys tender), the engine used (Cohere Command A+), and the shape of the output (fit, risks, next steps). An agent can distinguish this from lookup siblings like get_contract_details or get_opportunity_details, though the boundary with bid_no_bid_scorecard (also a fit assessment) is not addressed.

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 real precondition ('sign-in and an active workspaceAlberta Pro subscription required'), which is actionable usage context. However, it never says when to choose this over bid_no_bid_scorecard, classify_tender, or check_cohere_status, so the selection logic 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=true, so safety is covered. The description adds meaningful context beyond that: it is deterministic, makes no model call, and requires sign-in plus an active workspaceAlberta Pro subscription. It lacks details on rate limits or failure modes, but the added auth and determinism context is useful.

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 tightly written sentences with zero waste. The core purpose and evaluated dimensions are front-loaded, followed by the determinism and hosting prerequisites that an agent needs before invoking it.

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

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

For a one-parameter, read-only scoring tool with no output schema, the description covers what the tool returns (profile fit, runway, region, domestic-preference flags, go/caution/no-go verdict with reasons) and the subscription requirement. It is nearly complete, though it could say more about the verdict's output shape or edge cases.

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 is only one required parameter, and the schema fully documents it as a 'CanadaBuys or Alberta APC reference number' (100% coverage). The description reinforces that the tool operates on one opportunity but does not add format or syntax detail beyond the schema, so 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?

States a specific verb and resource: a deterministic bid/no-bid checklist for one opportunity, with the exact dimensions it evaluates (profile fit, runway, region, domestic-preference flags, verdict). The phrase 'No model call' explicitly distinguishes it from model-based siblings such as analyze_contract_with_cohere.

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

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

Gives clear context: use for one opportunity in any sector when you want a fast deterministic checklist rather than a model-based analysis, and notes the subscription prerequisite. It does not explicitly name sibling alternatives or exclusions, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral fact beyond annotations—that the tool does not call the model—but it does not describe the return value or any other runtime behavior. No contradiction with annotations.

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 each earning its place: the first states the primary purpose, the second rules out the most likely misreading. No 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 zero-parameter, read-only status check, the description is mostly complete. It explains what is checked and what is not done, but because there is no output schema it leaves the return shape (e.g., boolean vs status object) implicit.

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

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

The tool has zero parameters, so there is nothing for either the schema or the description to explain. The baseline of 4 applies because parameter ambiguity is nonexistent.

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 action (check whether configured), a specific resource (optional Cohere Command A+ model integration), and explicitly contrasts with calling the model. This makes it distinguishable from the sibling analyze_contract_with_cohere without needing 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?

The description makes the tool's role clear: verify configuration rather than invoke the model. It does not explicitly name alternatives or say 'use before X,' but the 'Does not call the model' sentence gives enough context for an agent to avoid selecting it for analysis. No exclusion or alternative is named, so it stops short of 5.

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

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

With annotations present, it still adds substantial behavior beyond them: clause/page text is sent to an external API (api.typesafe.ai), nothing is stored beyond the existing private bucket, PDF-only with ZIP extraction, 800-page/8,000-clause caps, 2-hour link expiry, non-deletion of uploads, 140-second runtime with a 'partial' label, classifier-output caveat, and sign-in + Pro subscription requirement. No contradiction with readOnlyHint=false or destructiveHint=false.

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

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

Every sentence is substantive, but they are packed into one dense unbroken paragraph that interleaves purpose, data-sharing disclosure, provider-specific flows, limits, and return format. A few bulleted lines or sentence grouping would make it far easier to scan; as written, the reader must parse a wall of text for a tool with only two parameters.

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, yet the description specifies the return shape (markdown plus JSON under schema wa.tender_requirements.v1 with closing time and posting link), the 140-second bound, and the partial-result marker. Given the external-API, two-source complexity, nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it frames reference as a CanadaBuys or APC identifier and explains that upload_token only applies to the APC second call, obtained from a prior classify_tender or process_bid_room result after the user uploads. This positions the parameters within the two-step flow in a way the schema does not.

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

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

Opens with a specific verb+resource: 'List what a bidder must supply for one tender', then names the pipeline (split into clauses, classify, group into one requirement per kind) and concrete outputs (mandatory flag, connector, lead time, page numbers, evidence quotes). An agent can distinguish this from siblings like process_bid_room or bid_no_bid_scorecard 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 clear when-to-use context split by source: CanadaBuys reads public attachments directly, Alberta APC requires the two-call upload flow with upload_token, and it explicitly notes process_bid_room can reuse the same token afterward. It does not name a when-not-to-use case or a competing classification tool, so it falls short of the top score.

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

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

Annotations already cover the read-only, non-destructive, open-world profile, yet the description adds real substance beyond them: the two data sources, that domestic-preference flags appear only when a matched notice carries them, and explicit disclosure that search terms/descriptions may be sent to Cohere and TypeSafe with /privacy pointers. That is exactly the kind of third-party data-flow context annotations cannot express. It stops short of five because it never says what the brief actually contains.

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 core purpose is front-loaded, but the prose is cluttered with overloaded internal jargon ('TypeSafe Jev supply classification') and two near-identical privacy sentences that could be compressed into one. Roughly half the text is disclosure boilerplate rather than operational guidance.

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 carries the burden of explaining return values, and it only hints at them ('brief', plus the `limit` schema's mention of 'items per section'). An agent cannot predict the brief's sections, ranking logic, or whether it includes deadlines vs. matches — important for a tool whose whole output is a synthesized report.

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%, including a fully documented nested `profile` object, so the baseline is 3. The description's only added semantic is 'for any business' / per-call inline profile, which is already stated in the profile schema description; it contributes nothing about `days` or `limit` beyond what the schema documents.

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 — generate a daily bid brief — scoped to the CanadaBuys and Alberta APC catalogues, and ties itself to find_business_fit's TypeSafe classification. It does not, however, distinguish itself from the many search/find siblings, so an agent still has to infer why it would choose a brief over find_matching_opportunities.

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 one concrete usage rule (pass an inline `profile` per call, which works without a saved profile) but never states when to prefer this tool over alternatives like find_business_fit, find_opportunities, or list_deadlines, nor any exclusion conditions. Usage is implied rather than prescribed.

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, openWorldHint, and destructiveHint=false, so safety is covered. The description adds meaningful non-obvious behavior: search terms or capabilities may be transmitted to Cohere for commodity filter selection, with a pointer to /privacy. That external-data-sharing disclosure is exactly the kind of context annotations cannot convey.

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

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

Three short sentences, front-loaded with the capability statement before the privacy caveat, with no filler. Slightly clipped by the dangling 'See /privacy' fragment, but nothing 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?

The read-only search behavior is well covered by annotations and the entire input surface is documented by the schema. What is missing is any hint of what comes back—result shape, ranking behavior from industry labels, or whether `limit`/`days` produce a truncated set—which matters given there is no output schema.

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

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

Schema description coverage is 100%, so all three parameters and the nested profile fields are already documented, and much of the description's profile guidance (inline overriding saved, capabilities derived from description) repeats the schema text. It adds only modest emphasis on 'per call' scope; baseline 3 applies when the schema does the heavy lifting.

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 Alberta Purchasing Connection opportunities') and adds the matching qualifier ('that match your business profile'), which distinguishes it from a bare keyword search. However, with siblings like find_matching_opportunities, find_opportunities, and search_alberta_opportunities present, it never names or contrasts with those alternatives, so the agent must guess which finder to pick.

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 real guidance on passing an inline `profile` per call and notes the inline profile overrides a saved one, which is useful context for choosing this over profile-based flows. But it says nothing about when to prefer this over find_opportunities, search_alberta_opportunities, or find_matching_opportunities, so tool-selection guidance is only implied.

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

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

Annotations declare readOnlyHint/openWorldHint/destructiveHint, and the description adds genuinely non-obvious behavior: a commodity-code and term prefilter, TypeSafe Jev classification of each notice with a yes/partial/no verdict plus capability label, a defined sort order (verdict, keyword score, Buy Canadian bonus), and a graceful degradation path when the key is rejected. It also discloses that the business description and notice text are sent to a third party (TypeSafe) with a /privacy pointer, which is exactly the kind of context annotations cannot convey.

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

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

The lead sentence is well front-loaded, but the closing two sentences restate the TypeSafe data-sharing disclosure already made mid-paragraph, including a second 'See /privacy.' That is roughly a third of the text spent on a verbatim repeat. Sentence two is also an overstuffed run-on mixing prefiltering, classification output, and sort order in one breath.

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 an output schema present, return values need no explanation, and the description covers the pipeline, the fallback, the ordering, the privacy/third-party disclosure, and the scope disclaimer. Minor gaps remain: the 'Buy Canadian bonus' and 'existing keyword score' inputs to ranking are named but never defined, and the relationship to saved profiles is left to the schema's profile description.

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%, including the nested profile object and its fields, so the schema already carries parameter meaning. The description adds indirect value by explaining that the commodity-code/term prefilter and the classification step consume the description and profile fields, but it gives no syntax, bounds, or interaction detail beyond what the schema states (e.g., days max 365, limit max 50).

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: rank open CanadaBuys and Alberta Purchasing Connection notices against a free-text business description, with the two-stage prefilter plus TypeSafe Jev classification spelled out. That is far more specific than the name alone. It does not, however, name or differentiate itself from close siblings such as find_matching_opportunities, find_opportunities, or search_contracts, which an agent must disambiguate on its own.

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 explains the internal routing conditions (Jev configured → classification ranking; not configured or key rejected → keyword ranking with a stated caveat), which is useful. But it never says when to choose this tool over its many siblings, and the only stated exclusion is that workspaceAlberta does not submit a bid or decide eligibility. Usage is implied by the two marketplaces covered, not guided.

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?

The description goes well beyond the read-only annotations by disclosing the ranking pipeline: commodity-code prefiltering, TypeSafe Jev classification, keyword scoring, Buy Canadian bonuses, and tie-breaking. It also transparently states when search terms or business descriptions may be sent to Cohere or TypeSafe and points to privacy documentation.

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 purpose is front-loaded and the description is generally efficient, with no wasted introductory prose. It is somewhat dense and repeats the privacy pointer twice, which prevents a perfect score despite the high-value behavioral details.

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

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

Given the nested profile object, annotations, and output schema, the description is largely complete for understanding what the tool does and how matching works. The main remaining gap is explicit guidance on when to choose this tool over sibling opportunity-search or fit-scoring 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?

Schema description coverage is 100%, so the schema already explains days, limit, and the nested profile fields. The description reinforces that profile is supplied inline per call, but it adds little parameter-level meaning beyond the schema and does not explain how days or limit behave.

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 uses a specific verb and resource: it ranks CanadaBuys and Alberta APC opportunities for a business profile. It implies a personalized matching purpose distinct from generic opportunity searching, but it does not explicitly name or distinguish itself from close siblings such as find_business_fit or find_opportunities.

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 tells the agent to pass an inline profile per call and implies use when ranked business-fit opportunities are wanted. However, it gives no explicit when-to-use versus alternatives, no exclusions, and no direct sibling routing guidance.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the description adds deposition status and a real auth/context constraint: anonymous hosted callers must supply an inline profile. It does not describe output shape or ranking behavior beyond the word "rank", but the added auth and legacy context clearly exceeds annotation coverage.

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

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

Three short sentences with the deprecation label front-loaded, then the preferred alternative, then the auth caveat. No sentence repeats the schema or the title, and nothing is wasted.

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

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

For a 3-parameter read tool with a nested profile object and no output schema, the description covers scope, deprecation, alternative, and the anonymous-caller requirement. It leaves unspecified what is returned (ranked list with score rationale) and what happens when no profile is supplied and no saved profile exists on non-anonymous calls, which is a minor 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 coverage is 100%, so the baseline would be 3, but the description adds semantics the schema does not: the profile parameter is effectively required for anonymous hosted callers even though the schema lists zero required parameters. That resolves a genuine ambiguity about conditional requirement that the schema alone leaves open.

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 (rank) and resource (federal CanadaBuys contracts) constrained against the caller's business profile, and explicitly marks itself as the legacy federal-only path. An agent can distinguish it from find_matching_opportunities and find_alberta_opportunities from the description alone.

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

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

"Prefer find_matching_opportunities for combined CanadaBuys and Alberta APC matches" names the alternative and the condition that selects it, and "Anonymous hosted callers must pass an inline profile" gives a hard invocation prerequisite. It stops short of saying when this tool remains the right choice over search_opportunities or find_alberta_opportunities, so it is strong guidance but not exhaustive routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns 'full details' for a reference, but does not disclose other behavioral aspects such as response shape or data freshness; the lack of contradiction is notable.

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

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

The description is a single, front-loaded sentence with a clear verb, resource, lookup key, and example. Every word earns its place and there is no redundant filler or repetition 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?

For a one-parameter, read-only lookup tool, the description, schema, and annotations are sufficient for correct invocation. The only minor gap is that it does not explicitly connect to search/find siblings for the broader workflow, but 'full details' sufficiently conveys the return intent.

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 schema already documents the reference parameter at 100% coverage, but the description adds value by clarifying the lookup mechanism and providing a concrete format example, 'AB-2026-03908,' which helps the agent construct a valid parameter value.

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 states the action and resource: 'Get full Alberta Purchasing Connection details by reference number.' It distinguishes itself from sibling tools like find_alberta_opportunities and search_alberta_opportunities, which are for discovery, by focusing on retrieval of a full record for a known reference.

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

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

The description implies usage when a caller already has a specific APC reference number, and gives a concrete example. However, it does not explicitly name alternatives or state when not to use this tool, so the agent must infer the routing from sibling tool names.

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=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context by labeling the tool 'legacy' and constraining it to CanadaBuys federal scope, but it says nothing about return format, coverage, or staleness beyond the legacy tag.

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, with the legacy scope constraint front-loaded before the routing recommendation. Every clause earns its place.

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

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

For a one-parameter read tool whose annotations cover the safety profile and whose only parameter is fully documented in the schema, this is nearly complete. A brief note on what the details response contains would close the 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?

There is a single parameter with 100% schema description coverage, so the schema already documents 'reference' as the reference or solicitation number. The description restates the same dual-key semantics without adding format, validation, or example detail. Baseline 3 applies when the schema does the heavy lifting.

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 ('get federal contract details'), names the source system (CanadaBuys), the lookup key (reference or solicitation number), and flags legacy status. It is immediately distinguishable from sibling tools like get_opportunity_details and get_alberta_opportunity_details.

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?

Explicitly routes the agent: use get_opportunity_details for federal or Alberta APC tenders, implying this tool is only for legacy CanadaBuys federal references. Both the preferred alternative and the condition selecting it are named, leaving nothing 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: that the returned profile is the one used for contract matching, and that access requires sign-in with no paid tier — useful constraints not present in the structured data.

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

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

Two short sentences, front-loaded with the purpose before the access note; nothing is wasted. The second sentence reads as a terse 'Hosted:' fragment rather than clean prose, but it is efficient.

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

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

For a zero-parameter read tool with no output schema, the description supplies purpose, the semantics of the returned profile, and the auth/subscription requirements. Nothing essential to invoking it correctly is missing, though the absence of any note on what fields the profile contains is a minor 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?

The tool takes zero parameters, so the schema carries nothing to misinterpret; there is no parameter semantics for the description to compensate for. 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?

States a specific verb and resource ('View your current business profile') plus its role in matching contracts, which cleanly separates it from the mutating sibling set_business_profile. It stops short of naming the sibling explicitly, so it is clear but not maximally differentiated.

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 prerequisite ('sign-in required; no paid subscription needed') and the general context that the profile drives contract matching, implying you call this to inspect the profile used for matching. It never states when to use this versus set_business_profile, so usage is only implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered and the bar is lower. The description adds real behavior beyond that: it discloses what the response contains and the important caveat that enrichment fields appear only 'when the source published them,' so agents can expect partial results. It stops short of describing failure behavior for unknown references.

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

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

A single front-loaded sentence with no filler; the verb, resource, and keyed scope come first, followed by the field list and the caveat. 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?

With no output schema, the description correctly compensates by listing the fields returned and flagging their conditional presence. For a read-only single-parameter lookup that is nearly sufficient; the remaining gap is disambiguation from get_alberta_opportunity_details.

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

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

Schema description coverage is 100% and there is a single required parameter, so the schema already explains the reference format with examples. The description only restates 'by reference number' and that either CanadaBuys or Alberta formats are accepted, adding no syntax or resolution guidance beyond the schema. Baseline 3 applies.

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

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

The description names a specific verb and resource (get details for an opportunity) and states scope: any federal CanadaBuys or Alberta APC record, keyed by reference number. It also enumerates distinguishing data fields (UNSPSC, GSIN, trade agreements, Buy Canadian flags). It does not, however, separate itself from the sibling get_alberta_opportunity_details, which appears to overlap on the Alberta portion.

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: the agent infers this is the lookup to call once it already has a reference number, versus find_opportunities/search_opportunities which produce candidates. No explicit when-to-use or when-not-to-use statement is given, and the presence of a sibling get_alberta_opportunity_details makes the routing ambiguous.

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, non-destructive and closed-world, so the safety profile is covered. The description still adds real value by disclosing 'No model or network call', which tells the agent there is no latency, cost, or external dependency. It stops short of describing the response format, which keeps it from a 5.

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

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

A single sentence, front-loaded with the call-to-action ('Start here when connecting an agent'), that packs the workflow scope, field handoff, boundaries, and the no-side-effect guarantee without a wasted clause.

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 parameterless guide with no output schema, the description adequately sets expectations about what the agent will learn. The only minor gap is that it does not indicate the shape of the returned guide (e.g. prose/markdown sections), which would help the agent plan how to consume it.

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. Nothing in the description needs to compensate for parameter documentation.

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 ('explains what workspaceAlberta does') and enumerates the content covered: workflow, handoff fields, data boundaries, unsupported actions. It is unmistakably the orientation doc and cannot be confused with any of the task-oriented siblings like search_opportunities or bid_no_bid_scorecard.

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?

'Start here when connecting an agent' gives explicit sequencing guidance that positions this ahead of every sibling tool. It does not enumerate when-not-to-use cases, but for a zero-parameter guide with no alternatives there is little else to route against.

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=true, and destructiveHint=false, so the read-only safety profile is covered. The description adds the filter context of 'open... closing soon' but does not disclose output shape, sorting, pagination, or other behavioral details.

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 entire description is one compact sentence with no filler. It front-loads the action, resource, and scope in that order, and every word contributes meaning.

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

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

For a simple, read-only list tool with zero required parameters and fully documented schema, the definition is nearly complete. The main gap is the lack of any return-shape description since there is no output schema, but an agent can safely and correctly invoke the tool based on the provided information.

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

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

Schema description coverage is 100%, and all three parameters have clear descriptions plus defaults/max. The description itself adds no new parameter semantics, so the baseline score of 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 uses a specific verb ('List'), names a distinct resource ('Alberta Purchasing Connection opportunities'), and constrains scope ('open... closing soon'). This makes it distinguishable from generic siblings like list_deadlines or list_upcoming_deadlines.

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 phrase 'closing soon' implies the intended use case: surfacing imminent procurement deadlines. However, the description offers no explicit guidance about when to choose this tool over alternatives such as find_alberta_opportunities or list_upcoming_deadlines, and no exclusion criteria.

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=true, so the safety profile is fully covered. The description adds only the aggregation scope across two procurement sources; it says nothing about ordering of deadlines, truncation behavior, or how combined results are interleaved, which are the traits that actually matter for this tool.

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

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

A single front-loaded sentence with zero filler, which is appropriately sized for a simple list tool. It is slightly under-specified rather than wasteful: 'closing soon' is never tied to the default 30-day horizon that the schema actually defines.

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 five optional params, a full output schema, and strong annotations, most invocation detail is carried by structured fields, so the description needs only routing context. The missing piece is exactly that: differentiation from list_upcoming_deadlines and list_alberta_deadlines, which share almost the same semantics.

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

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

Schema description coverage is 100% and every parameter (days, limit, source, category, province) is self-documented with defaults and enumerated-ish values, so the schema does the heavy lifting. The description adds no extra parameter meaning, 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 gives a clear verb+resource (list opportunities closing soon) and names the two data sources, CanadaBuys and Alberta APC. However, it does not distinguish this tool from near-identical siblings such as list_upcoming_deadlines and list_alberta_deadlines, so an agent cannot tell from the description which one to call.

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 use this tool, when not to, or which sibling to prefer. The only implicit signal is the 'CanadaBuys and Alberta APC' scope, which loosely maps to the source parameter, but a caller facing list_upcoming_deadlines has no textual reason to choose one over the other.

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=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it is legacy, limited to federal CanadaBuys deadlines, and should be deprioritized for combined data. It does not describe return format or pagination, but the added scope and deprecation context are meaningful.

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 zero filler. The legacy status and scope limitation are front-loaded, followed immediately by the routing advice, making the definition easy to scan.

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

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

For a simple read-only list tool with full parameter coverage in the schema and annotations covering safety, the description supplies everything an agent needs to call it correctly: purpose, scope, and the preferred alternative. No output schema exists, so return-value details are not required 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 description coverage is 100%, and both parameters (days, province) are fully documented in the schema. The description adds no syntax, format, or meaning beyond what the schema already provides, so the baseline score 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 states a specific resource and scope: 'federal CanadaBuys closing deadlines only.' It also explicitly distinguishes itself from list_deadlines, which covers combined CanadaBuys and Alberta APC results. An agent can identify exactly what this tool returns without opening the schema.

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

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

It names the preferred alternative (list_deadlines) and the condition that selects it ('for combined CanadaBuys and Alberta APC results'). The 'Legacy' label further signals that this tool should generally be avoided unless federal-only deadlines are specifically needed.

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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: the host requirement (sign-in plus an active workspaceAlberta Pro subscription) and the sort order and returned fields.

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, zero waste, and the core action is front-loaded before the hosted-prerequisite note. Every clause earns its place by adding sorting, field, or auth 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?

There is no output schema, so the description usefully compensates by naming what is returned (closing date sort, days remaining, notes). With no parameters and annotations covering safety, the only minor gap is that no pagination or result-size behavior is mentioned.

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 calibration baseline this scores 4. The schema is empty with 100% coverage, and the description correctly adds no parameter claims that would conflict.

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

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

The description states a specific verb and resource ('List watched opportunities') and adds scope detail (sorted by closing date, includes days remaining and notes). The watchlist resource is unique among the siblings (watch_opportunity/unwatch_opportunity are mutations of it), so an agent can identify this read-only listing without ambiguity.

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

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

Usage is only implied: an agent can infer this is the way to view items the user previously saved, but there is no explicit statement of when to use this versus siblings like list_deadlines, find_opportunities, or get_opportunity_details, and no exclusions 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?

Annotations already declare readOnlyHint and destructiveHint=false, so the safety profile is covered. The description still adds genuinely useful context beyond them: it discloses that non-applicable Ontario streams are labeled, and explicitly states that workspaceAlberta does not apply for funding or decide eligibility, which sets an important authority boundary.

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 opening clause is well front-loaded, but the bulk of the description is a long run-on enumeration of specific program names that is more marketing copy than decision-relevant information for an agent selecting a tool. The final disclaimer earns its place; the program list largely does not.

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 should describe what a caller gets back. It hints at an 'applies section' only indirectly through the limit parameter and never explains sections, ranking, or result shape, leaving a meaningful gap for a tool whose value is in structured matching results.

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 fully documents the six parameters including the nested profile object. The description adds essentially nothing about parameter behavior, only the incidental phrase 'applies section' which loosely relates to the limit parameter. Baseline 3 applies when the schema carries this weight.

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 (a read-only catalog of industrial and tariff support programs) and enumerates the covered programs, so its domain is unmistakable against siblings that deal in contracts and tenders. There is a mild verb mismatch: the tool name says 'match' while the description frames it as a 'catalog', leaving some ambiguity about whether matching/ranking is performed or just listing.

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?

'For any Canadian business' and 'an Alberta firm can ask about' imply the audience, and the Ontario-only labeling note clarifies scope. But there is no explicit when-to-use statement, no exclusions relative to sibling tools (e.g., find_alberta_opportunities), and no stated prerequisites, so the agent must infer placement in the workflow.

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?

Adds context well beyond the annotations: the concrete 145-second wall-clock bound, that large packages may time out, that timeouts must not be treated as completed analyses, the APC two-step upload handshake, privacy/processing locations, and the hosted sign-in plus active subscription requirement. For a non-read-only, open-world tool these are exactly the operational facts an agent needs before invoking.

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 what the tool does and the E2B/Cohere pipeline, then the APC special case, then limits and auth. Sentences are dense but each carries distinct operational information; only the privacy-location sentence feels like boilerplate.

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 carry return-value expectations, and it partially does: it says what goes to Cohere and that the first APC call returns a private upload link, plus the timeout envelope. It never describes the shape of a successful result (evidence set, scorecard fields), which is the remaining gap for a six-parameter nested-object 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 coverage is 100%, so the schema already documents all six parameters including upload_token, max_attachments and apc_document_urls. The description adds operational framing for the APC token flow but says nothing about max_attachments=0 notice-only reviews or profile-override behavior that the schema itself carries. 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?

States a specific verb+resource: it processes a tender's attachments by sending them to E2B and Cohere Parse/Command A+ and returning extracted evidence, keyed by a CanadaBuys or APC reference. That is far more than a restatement of the name. It stops short of naming which sibling to use instead (analyze_contract_with_cohere, classify_tender), so differentiation is only implicit.

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 concrete call conditions: call with a reference, and for Alberta APC expect a first call that returns a private upload link, then a second call with upload_token. It also gives retry guidance ('retry with fewer attachments') and warns a timeout is not a completed analysis. It does not state when to prefer this over analyze_contract_with_cohere or the other analysis siblings.

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

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

The annotations indicate this is a read operation (readOnlyHint: false) and not destructive (destructiveHint: false), but openWorldHint: true suggests it may involve external calls. The description adds minimal context: it mentions the data source (CanadaBuys) but does not reveal implications like potential timeouts, rate limiting, or that it may overwrite cached data. It neither contradicts nor significantly extends the annotations.

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

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

The description is extremely short (one sentence) and front-loads the action ('Refresh') and the resource ('contract data from CanadaBuys'). It is concise and structured appropriately for the simple nature of the tool. Every word is relevant, with no 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?

Given the tool has no parameters and a simple operation, the description is largely complete; however, it lacks any context about the result of the operation, such as what the refreshed data is used for, any side effects, or how it relates to the other data tools. Without an output schema, the description needs to convey this, and it does not.

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

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

With zero parameters and high schema coverage (100%), the description has no parameter details to add. The description and schema align: there are no parameters to explain. This tool requires no input, so the description correctly omits parameter semantics.

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 action ('Refresh') and the resource ('contract data from CanadaBuys'), which is a clear verb+resource. However, it does not distinguish it from other operationally similar tools like 'summarize_contracts' or 'search_contracts' beyond the refresh verb, potentially confusing an agent about the exact data source scope.

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

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

There is no explicit guidance on when to use this tool versus the many sibling tools. The description does not specify scenarios like 'use when you need the latest data' or alternatives such as 'search_contracts' for querying. This omission means an agent must infer usage from the title and description 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds a genuinely non-obvious behavioral trait: search terms or business capabilities may be forwarded to a third-party service (Cohere) to derive commodity filters. That kind of external data-flow disclosure is not derivable from schema or annotations, though pagination/result-shape behavior is still unaddressed.

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 no filler. The privacy/Cohere sentence is short and relevant, though it slightly displaces the usage guidance an agent would find more actionable.

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

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

For a 4-parameter, all-optional search with full schema coverage and no output schema, the description covers the what and a privacy caveat but omits selection context relative to the crowded sibling set (find_alberta_opportunities, search_opportunities, find_matching_opportunities). Adequate but leaves a real routing 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 100%: limit (default/max), status (default), category (services/goods/construction), and keywords are all documented in the schema. The description adds no format, syntax, or defaulting detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Search Alberta Purchasing Connection opportunities from Alberta public-sector buyers', which is clear about the data source. However, it does not differentiate itself from closely-named siblings like find_alberta_opportunities, find_matching_opportunities, or search_opportunities, so an agent cannot tell which of these to pick from the description alone.

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

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

No when-to-use guidance, no conditions that distinguish it from the many other opportunity-search siblings, and no exclusions. The only extra sentence concerns Cohere data transmission and a privacy pointer, not selection criteria.

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, openWorldHint and destructiveHint, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations cannot: the legacy/deprecated status and the fact that results come from the federal CanadaBuys source only. It stops short of describing result shape or pagination, keeping it from a 5.

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

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

Three short sentences with zero padding; the legacy status and source scope come first, followed by capability and then the preferred alternative. Nothing is repeated from the annotations or the 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?

An agent has enough to decide between this tool and search_opportunities, and the read-only annotations plus fully documented schema cover the remaining risk. Only the return format (e.g., contract summaries vs. full records) is left unspecified, which is minor for a no-output-schema list 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 100%, with all three parameters (limit, keywords, province) documented in-schema with examples. The description mentions keyword and province filtering but adds no semantic 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?

States the specific resource and its source scope ('Legacy: federal CanadaBuys only') and names the filtering capability, so an agent can tell exactly what corpus it searches. It explicitly contrasts with the sibling search_opportunities, which is the closest alternative.

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 routing rule: 'Prefer search_opportunities for combined CanadaBuys and Alberta APC results,' naming both the alternative and the condition that selects it. 'Legacy' also signals this should be a fallback rather than the default 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?

Annotations already cover read-only, open-world, and non-destructive semantics, so the description goes beyond them by disclosing third-party data flows: search terms or capabilities may be sent to Cohere for commodity filter selection and notice text plus the business description to TypeSafe for supply-fit classification, each with a /privacy pointer. This is meaningful behavioral context an agent would not otherwise have, though result caps and pagination (beyond the limit parameter) are not described.

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 scope statement and the out-of-scope exclusion first, and each subsequent sentence covers a distinct mode (ranking, keyword-only, Cohere, TypeSafe). The repeated 'See /privacy.' after two sentences adds minor redundancy.

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

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

Given nine optional parameters, a nested profile object, an output schema, and full schema coverage, the description supplies the missing pieces: what gets searched, how ranking is triggered, and what is transmitted externally. Return shapes are covered by the output schema, so remaining gaps are minor.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics the schema lacks: description/profile trigger fit classification that runs before keyword ranking, keyword-only queries remain lexical, and capability terms may be forwarded to Cohere. That clarifies the interaction between keywords, category, description, and profile rather than restating field docs.

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 (Search) and resource (open CanadaBuys and Alberta Purchasing Connection notices), and explicitly denies a narrow scope ('Results are not limited to steel, lumber, aluminum, or construction'). It does not name or differentiate itself from close siblings such as find_opportunities, search_alberta_opportunities, or find_matching_opportunities, leaving the agent to infer boundaries.

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 internal mode switch well: 'Pass description or profile to rank by a TypeSafe Jev supply-fit classification... Keyword-only searches stay lexical.' However, it never says when to choose this tool over the many sibling search/find tools, so the when-to-use guidance is implied rather than stated.

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?

The annotations already declare readOnlyHint=false, openWorldHint=false, and destructiveHint=true, so the safety profile is covered. The description adds useful context about hosting, sign-in, and no paid subscription, but it does not disclose what gets overwritten or destroyed when saving a profile.

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-load the purpose and include an important prerequisite. The opening 'Tell me about your business' is slightly conversational, but overall the description is efficiently sized.

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

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

Given the simple three-parameter schema and existing annotations, the description is mostly complete for a save operation. However, it omits the important destructive behavior of overwriting or replacing an existing profile, which is signaled by destructiveHint=true.

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 all three parameters are already documented in the input schema. The description adds no parameter-specific syntax, constraints, or format details beyond the schema baseline.

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

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

The description names a specific action ('save your profile') and resource ('business profile'), and explains its downstream purpose ('find matching government contracts'). It is clear on its own, but it does not explicitly differentiate itself from siblings such as get_my_profile.

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 instruction 'Tell me about your business' and the sign-in prerequisite, but there is no explicit when-to-use guidance or comparison with alternatives like get_my_profile. The agent must infer that this is the setup/update tool.

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=true, and destructiveHint=false, covering the safety profile. The description adds behavioral scope ('current open' and 'by category') but does not disclose what a summary contains (e.g., counts, values, dates) or any limitations, which matters since no output schema exists.

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

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

The description is a single, tightly worded sentence that front-loads the action and scope. Every word contributes meaning ('current open', 'Alberta Purchasing Connection', 'by category'), with no filler or redundancy.

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

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

For a zero-parameter tool with no output schema, the description is nearly complete: it names the source, the filter (open), and the grouping. The only gap is that 'summarize' is not fully specified—an agent might wonder whether the output is a text narrative or structured data—but the tool's simplicity and annotations keep this from being a major deficiency.

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, so the input schema covers everything vacuously. The baseline for 0 params is 4, and the description adds no unnecessary parameter details. No further semantic documentation is needed.

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 uses a specific verb ('Summarize') with a clear resource ('Alberta Purchasing Connection opportunities') and scope ('current open... by category'). It distinguishes itself from siblings like find_alberta_opportunities or get_alberta_opportunity_details, which perform search or detail retrieval, by emphasizing the grouping behavior.

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

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

The description implies a use case—obtaining a categorical overview of open opportunities—but does not explicitly state when to prefer this over alternatives or when not to use it. Sibling names are provided in context but the description itself offers no exclusions or comparisons, so guidance is only implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: it is flagged as legacy and its data scope is bounded to federal CanadaBuys with Alberta APC excluded. It stops short of describing the summary's output format, but the added scope and deprecation context is strong.

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 zero waste, front-loading the 'Legacy' status so an agent immediately knows the tool's standing. Every clause earns its place by either scoping or redirecting.

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 summarizer with no output schema, the description covers scope, deprecation, and routing well. The only gap is that it does not hint at what the summary contains or its granularity, which is minor given the tool's simplicity.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No parameter syntax or defaults are needed 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?

States a specific verb (summarize) and a precisely scoped resource (federal CanadaBuys contracts only), and explicitly carves itself out from the broader toolset. An agent can distinguish it from search_opportunities, daily_bid_brief, and the Alberta APC tools without opening any schema.

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

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

Gives explicit routing: for combined discovery use search_opportunities or daily_bid_brief, and notes this summary excludes Alberta APC. The alternative and the condition selecting it are both named, leaving nothing 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 flag destructiveHint=true and readOnlyHint=false, so the removal semantics are covered. The description adds genuinely useful context the annotations lack: the hosted deployment requires sign-in and an active workspaceAlberta Pro subscription. It does not state whether removal is reversible or what happens if the reference is not found, keeping 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?

Two tight sentences with the action front-loaded and the access constraint following. No redundant or filler content.

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

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

For a one-parameter, non-open-world destructive tool with no output schema, the description covers the action, the identifier, and the access requirements. It could go further by noting irreversibility or behavior on an unknown reference, but nothing essential to invoking it correctly is missing.

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

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

Schema description coverage is 100% and the single parameter is already documented as 'Reference number to stop tracking.' The description's mention of 'by reference number' only restates the schema, so the baseline 3 applies.

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

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

States a specific verb (remove), resource (watchlist entry), and identifier (reference number) in one sentence. The inverse relationship to the sibling watch_opportunity is self-evident, but the description does not explicitly differentiate itself from list_watchlist or other watchlist 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?

The intended action is implied clearly by 'remove an opportunity from the watchlist,' but there is no explicit when-to-use guidance, no statement of prerequisites beyond auth, and no mention of alternatives such as list_watchlist for viewing entries first.

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, destructiveHint=false, openWorldHint=true, and the description adds the meaningful detail that the watchlist is persistent and that auth/subscription is required. It stops short of covering edge behavior such as duplicate references or whether the note is editable later.

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, front-loaded with the action and resource, followed by the auth prerequisite. No wasted text.

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

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

For a two-parameter, non-read-only tool with no output schema, the definition covers purpose, sources, persistence, and access requirements. Minor gap: no statement of what happens on a duplicate add or how the note is used.

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 both parameters are already documented in the schema. The description's mention of the optional note adds nothing beyond it; 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?

Specific verb (Add) plus resource (opportunity to watchlist), and it names the two source systems (CanadaBuys, Alberta APC). Clearly distinguishable from its siblings unwatch_opportunity and list_watchlist.

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?

States the prerequisites explicitly: sign-in and an active workspaceAlberta Pro subscription are needed for the hosted path. It does not explicitly route the agent toward or away from siblings (e.g., when to use watch vs. list_watchlist first), but the context is unambiguous.

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