workspace-alberta

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's contribution is the auth/subscription requirement and the note that it runs on a hosted Cohere Command A+ model. That is real operational context beyond the annotations, though it doesn't cover latency, rate limits, or failure modes.

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: the first states the action and outputs, the second states the access prerequisite. Front-loaded and free of 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 read-only analysis tool with full schema coverage and no output schema, the description covers what it does, what it returns conceptually, and the access requirement. Only the omission of alternatives/usage routing keeps it from being fully complete.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the nested profile object and its fields. The description adds no syntax or format detail beyond what the schema provides, which is the expected 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?

Names a specific verb (review/analyze), a specific resource (CanadaBuys tender), and the concrete outputs (fit, risks, next steps), which separates it from generic summarizers like summarize_contracts. It does not explicitly name or contrast a sibling tool, so it falls short of the top band.

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 gives a prerequisite ('sign-in and an active workspaceAlberta Pro subscription required') but no guidance on when to choose this over siblings such as bid_no_bid_scorecard or get_contract_details. There are no when-not conditions or named alternatives.

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

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

Adds meaningful context beyond the annotations: it is deterministic and fast with no LLM call, and it requires sign-in plus an active workspaceAlberta Pro subscription. These auth/prerequisite and cost/latency details are exactly what annotations (readOnlyHint, destructiveHint, openWorldHint) do not convey. It does not describe rate limits or failure modes, so not a 5.

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

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

Two tight sentences, front-loaded with the core purpose and scoring factors, then a short prerequisite clause. 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?

With no output schema, the description helpfully enumerates what the verdict contains (fit, runway, region, go/caution/no-go with reasons), which is what an agent needs to decide to call it. Auth prerequisites are covered. Minor gaps around error behavior or reference-format edge cases keep it from 5.

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

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

Schema coverage is 100% and only one parameter exists, so the schema already documents 'reference' as a CanadaBuys or Alberta APC reference number. The description adds nothing about accepted reference formats beyond what the schema states; 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 ('bid/no-bid checklist for one opportunity') plus the scope of evaluation (profile fit, runway to closing, region match) and the output form (go/caution/no-go verdict with reasons). It is also distinguishable from siblings like analyze_contract_with_cohere via 'No model 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?

Frames the use case clearly: assessing a single opportunity quickly and deterministically. 'No model call' implicitly routes the agent away from the Cohere-based analysis sibling, but no alternative is named explicitly and no when-not-to-use condition is given.

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

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

Annotations 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 declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds meaningful non-obvious behavior: the brief is free, search terms/capabilities may be transmitted to Cohere, and a privacy link is provided — exactly the kind of third-party/rate/data-handling context annotations cannot express.

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

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

Three sentences, purpose front-loaded, with the Cohere/privacy caveat placed last where it belongs. No filler, though the profile-override sentence duplicates schema 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?

No output schema exists, so the description carries some burden for explaining the return value, and it only vaguely implies a 'brief' with sections implied by `limit` ('Maximum items per section'). A nested `profile` object plus no described output structure leaves the returned shape under-specified for an agent.

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 days/limit/profile are already documented in the schema, and the description largely restates the profile-override behavior that the schema already states ('Overrides any saved profile'). It adds marginal value beyond the structured fields, 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?

The description opens with a specific verb and resource ('Generate a free daily bid brief') and names the two data sources (CanadaBuys, Alberta APC) plus the input that drives it (a business profile). This distinguishes it from generic searchers like search_opportunities, though it never explicitly names a sibling 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?

It tells the agent to pass an inline `profile` per call, which is genuine usage guidance, but there is no explicit when-to-use-this-vs-alternatives statement (e.g. vs find_matching_opportunities or get_my_profile). Usage is implied by the 'daily brief' framing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuine value beyond that: it discloses that search terms or business capabilities may be sent to a third party (Cohere) for commodity filter selection, and points to /privacy, which is a meaningful data-handling disclosure an agent should know.

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

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

Three sentences, front-loaded with purpose and then the key usage and privacy notes; little waste. The /privacy pointer is terse but purposeful. Slightly more compaction is possible but structure is good.

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

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

With no output schema and a nested-object profile, the description never says what the returned opportunities look like (fields, ordering, count behavior). Parameters are well covered by the schema, so the main gap is return-value expectation, which for a search tool an agent would benefit from knowing.

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 days, limit, and the nested profile fields are already documented in the schema. The description adds only marginal meaning — the per-call override semantics and the Cohere-derived capabilities — so the baseline 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?

States a specific verb and resource ('Find Alberta Purchasing Connection opportunities') and adds a matching criterion tied to the business profile, so the agent knows what it retrieves. It does not distinguish itself from close siblings such as search_alberta_opportunities, find_matching_opportunities, or find_opportunities, which an agent could easily confuse it with.

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 implies when to use the inline `profile` ('the way to describe your business' on the public endpoint) but gives no explicit when-to-use vs. when-not guidance relative to the many sibling search/find tools. Usage is inferable from the profile-override note 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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), but the description adds real behavioral context beyond them: it discloses that search terms/business capabilities may be transmitted to Cohere and points to /privacy. This third-party data-sharing note is meaningful and not present in the structured fields, though ranking behavior is still unexplained.

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, purpose front-loaded, no filler. The closing 'See /privacy' is a slightly dangling reference but still earns its place as a pointer to the disclosure it summarizes.

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 output schema exists, so return-value explanation is unnecessary, and the nested profile object is fully documented in the schema. The description covers purpose, the inline-profile mechanism, and the privacy implication; only the ranking method and the relation to saved-profile tools are left implicit, which is a minor gap for this complexity.

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

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

Schema description coverage is 100%, including the nested profile fields (location, industries, description, capabilities, company_name) and the day/limit defaults, so the schema does the heavy lifting. The description only adds that the profile is inline and per-call, which the schema already states, so baseline 3 is correct.

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 ... opportunities against a business profile') and names the two data sources (CanadaBuys, Alberta APC). It is distinguishable from generic siblings like search_opportunities or find_opportunities by being profile-driven ranking, though it never explicitly contrasts itself with them.

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

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

The description tells the agent to pass an inline `profile` per call, implying usage when no saved profile exists, but it gives no explicit when-to-use/when-not guidance and never names a sibling alternative (e.g., why use this instead of find_opportunities or set_business_profile first). 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, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds context the annotations cannot: it is a legacy tool, the search scope is federal-only, and anonymous hosted callers need an inline profile (an auth-shaped constraint). It does not describe ranking behavior or result richness, but that is a minor gap given 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, each carrying distinct load: scope, preferred alternative, caller requirement. The legacy/deprecation status is front-loaded, which is exactly the information an agent needs first.

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, fully-documented, no-output-schema read tool with readOnly/openWorld annotations, the description covers the deprecation routing and the caller constraint. It is nearly complete; only ranking/return-shape nuance is absent, which is acceptable given the tool's legacy status and the sibling that supersedes 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?

Schema description coverage is 100%, so the schema already documents days, limit, and every nested profile field, including the note that profile overrides a saved profile. The description adds no semantics for these parameters beyond repeating the profile-override idea, 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: rank federal CanadaBuys contracts against your business profile. It explicitly scopes the source to CanadaBuys only, which is the exact axis that separates it from find_matching_opportunities (combined CanadaBuys + Alberta APC). An agent can distinguish it from siblings without opening a 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?

Explicitly names the preferred alternative (find_matching_opportunities) and the condition selecting it (combined CanadaBuys and Alberta APC matches). It also gives a prerequisite for a specific caller class: anonymous hosted callers must pass an inline profile. Both when-to-use and when-not are covered.

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 and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond that—it does not mention what happens if the reference is invalid, whether results are cached, or any rate limits. With annotations present, the description could have added value by elaborating on the openWorldHint or potential variations in returned data, but it does not.

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

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

A single sentence with no filler. The essential information—action, scope, and required input—is front-loaded and directly stated. Nothing extraneous.

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 operation with one parameter and no output schema, the description is mostly adequate. However, it does not specify what 'details' includes or how this tool differs from the sibling get_alberta_opportunity_details. The absence of an output schema means the agent must infer the return structure from the name alone, which is a gap. A slightly richer description clarifying scope or expected response would improve completeness.

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

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

Schema description coverage is 100%, and the schema already describes the reference parameter with examples ('AB-2026-03908 or a CanadaBuys reference'). The tool description merely repeats 'by reference number' without adding any new meaning or clarifying format constraints. Baseline 3 is appropriate given the schema's completeness.

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 verb 'Get' and the resource 'details for a federal CanadaBuys or Alberta APC opportunity by reference number'. It is specific and unambiguous, distinguishing itself by covering both federal and Alberta opportunities, even though it doesn't explicitly contrast with sibling get_alberta_opportunity_details. The purpose is immediately apparent.

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 provides no explicit guidance on when to use this tool versus alternatives like get_alberta_opportunity_details or find_opportunities. It only states the action and input, leaving the agent to infer that a reference number is sufficient. No exclusions or alternative conditions are mentioned.

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, establishing the safe, non-mutating nature. The description adds the valuable detail 'No model or network call,' which goes beyond the annotations to clarify that invoking this tool incurs no external side effects or dependencies. This extra context helps an agent reason about operational cost and reliability, though it does not describe the return format (e.g., plain text vs. structured output), which would be useful but is somewhat expected for a guide.

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 concise: two sentences that front-load the key directive ('Start here') followed by a precise list of guide contents. Every word adds value, and there is no redundancy or padding. The structure is ideal for quick agent scanning.

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 guide tool with no parameters and no output schema, the description is complete. It specifies what the guide contains (workflow, handoff fields, data boundaries, unsupported actions) and declares the absence of model/network calls. An agent has everything it needs to decide to call this tool and know what to expect.

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

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

The tool takes zero parameters, and the schema reflects this with an empty properties object. Per the baseline for 0-parameter tools, a score of 4 is appropriate because there are no parameters to explain. The description correctly omits any parameter details, so no gap exists.

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 tool's purpose: it is a guide that explains WorkspaceAlberta's workflow, handoff fields, data boundaries, and unsupported actions. The verb is implied ('start here'), the resource is explicit (the WorkspaceAlberta guide), and it is clearly distinct from sibling tools that perform searches or retrievals. No 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?

The description explicitly says 'Start here when connecting an agent,' which provides direct, actionable guidance on when to invoke this tool. It also sets expectations for what the guide covers, making it clear that it is the entry point for onboarding rather than a domain operation. No alternatives are needed because the tool is uniquely positioned as a guide.

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 and open-world profile is covered. The description adds only the source scope (CanadaBuys + Alberta APC), and says nothing about ordering, pagination, or what 'closing soon' resolves to beyond the schema default of 30 days.

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 tight sentence with the source scope front-loaded and zero waste. It is efficient, though the brevity comes at the cost of the disambiguation the tool actually needs.

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 output schema exists so return values need not be explained, but the description leaves the critical ambiguity unresolved: which of the three deadline-listing siblings to call. For a zero-required-parameter tool easily confused with its neighbors, that omission is significant.

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 five parameters carry defaults, enums-by-name, and constraints (e.g. max 50) in the schema itself. The description adds no syntax, unit, or format meaning beyond what the schema already provides, 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?

Specific verb ('List') plus resource ('opportunities closing soon') and names the two source domains CanadaBuys and Alberta APC, so an agent knows what it retrieves. However it does nothing to distinguish itself from the near-identical siblings list_upcoming_deadlines and list_alberta_deadlines, which is the main risk for this tool.

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 statement, no prerequisites, and no mention of alternatives. With three name-adjacent siblings (list_deadlines, list_upcoming_deadlines, list_alberta_deadlines) all covering deadlines, the agent is left to guess which one applies.

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?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing data flows and destinations (E2B, Cohere Parse/Command A+, /privacy), a hard 145-second latency bound, timeout semantics, retry behavior, and hosted auth/subscription prerequisites. This is exactly the behavioral context annotations cannot carry.

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-loads the core pipeline, then layers privacy, APC flow, timeout and auth in a logical order with every sentence carrying operational weight. It is dense and repeats the upload_token APC flow already stated in the schema, costing a little efficiency.

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 6-parameter, nested-object, no-output-schema tool, it covers the two-step APC return (upload link), timeout budget, retry policy and auth requirements thoroughly. It does not describe what a successful analysis returns, which matters given there is no output schema to fall back on.

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

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

Schema coverage is 100% and the schema already documents profile, reference, upload_token, max_attachments, business_context and apc_document_urls in detail, so the baseline is 3. The description largely restates the APC upload_token flow already present in the parameter description and adds no new syntax or constraints.

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

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

States a specific verb and resource and details the pipeline ('sends documents and business context to E2B, PDF page images... to Cohere Parse and Command A+'), so the agent knows this is the deep document-processing tool rather than a lookup. It never names a sibling (e.g. analyze_contract_with_cohere) to sharpen the boundary, so differentiation is inferential rather than explicit.

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 conditional flows: the two-step APC path (first call returns a private upload link, call again with upload_token), retry guidance ('Retry with fewer attachments'), and the timeout caveat ('a timeout is not a completed analysis'). It stops short of saying when to prefer a different sibling tool, so it is clear context without explicit alternatives.

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

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

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds scope context beyond the annotations: it is legacy and covers federal CanadaBuys data only, not Alberta APC. It does not mention pagination or result-shape behavior, but with annotations carrying the safety burden this is solid.

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, zero waste, with the legacy status and scope stated first and the routing recommendation last. Every sentence 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 read-only, three-optional-parameter search tool with no output schema, the description plus full schema coverage gives an agent what it needs to call and correctly route the tool. The remaining gap is purely that behavioral details like result count defaults are left entirely to the 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 (limit, keywords, province) are already documented in the schema. The description restates keywords and province as filters but adds no format or syntax detail beyond what the schema provides, and never mentions limit. Baseline 3 is appropriate 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 ('federal CanadaBuys' contracts) plus the filterable dimensions (keywords, province), and explicitly differentiates itself from the sibling search_opportunities by data coverage. An agent can tell exactly what this returns versus the broader opportunity search without opening either 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?

Explicitly labels itself 'Legacy' and instructs 'Prefer search_opportunities for combined CanadaBuys and Alberta APC results', naming the alternative and the condition that selects it. The only minor gap is that it doesn't say when this legacy tool is still the right call (e.g., CanadaBuys-only queries), but the routing intent is unmistakable.

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 non-annotation context: that search terms or business capabilities may be transmitted to a third party (Cohere) for commodity filter selection, with a privacy pointer. Pagination specifics are absent, but the output schema covers returns.

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

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

Two short sentences, front-loaded with the core action and scope, followed by the privacy disclosure relevant to the Cohere behavior. No filler, though 'See /privacy' is a somewhat opaque redirect rather than inline 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 annotations covering safety, a full output schema, and 100% parameter coverage, the description only needs to add scope and behavior. It does both (dual-source coverage plus third-party data transmission), leaving only the sibling-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%, so the schema already documents all five parameters including limit, source, category, keywords, and province. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (search) and resource (procurement opportunities) and names both underlying sources (CanadaBuys and Alberta Purchasing Connection), which implicitly sets it apart from alberta-only siblings like search_alberta_opportunities. However, it does not distinguish itself from other overlapping siblings such as find_opportunities or find_matching_opportunities, leaving ambiguity about which one 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?

The mention of searching both sources 'together' implies this is the combined/cross-source option, giving implied usage guidance versus single-source siblings. But there is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer.

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.