workspace-alberta

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context by naming the external model (Cohere Command A+) and clarifying the task is explanatory, reinforcing the read-only nature. It does not contradict 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 a single 16-word sentence that front-loads the action and result. Every word earns its place, with no filler or repetition of the tool 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?

Given the tool has 5 parameters, a nested object, and no output schema, the description covers only purpose and does not mention key behaviors like inline-vs-saved profile precedence or the shape of the returned analysis. The schema's profile description partially compensates, but the overall description is not 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 all five parameters (reference, profile, question, max_tokens, business_context) are already documented. The description adds no additional parameter meaning, which is acceptable since the schema carries the full burden.

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 ('review') and resource ('CanadaBuys tender'), with clear deliverables: 'explain fit, risks, and next steps'. It distinguishes itself from siblings like get_contract_details (retrieval) and summarize_contracts (summary) by focusing on evaluative analysis, though it doesn't explicitly name an 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?

The description gives no explicit guidance on when to use this tool versus alternatives like bid_no_bid_scorecard or summarize_contracts. The intended use case is implied by the verb 'review' and the deliverables, but there is no when-to-use or when-not-to-use direction.

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 openWorldHint, so the safety profile is covered. The description adds 'Fast deterministic' and 'No model call', which discloses performance and execution behavior beyond the annotations. It also describes the verdict outcome ('go/caution/no-go verdict with reasons'), providing useful behavioral context.

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

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

The description is two sentences with zero waste. It front-loads the purpose and criteria, then adds a final clarifying note about determinism. Every clause earns its place, making it an exemplary concise definition.

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

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

For a single-parameter, read-only tool with no output schema, the description covers the essential context: what it does, what criteria it evaluates, and the nature of the verdict. It leaves out the exact output format, but the lack of an output schema and the simplicity of the tool make this acceptable. The description is complete enough for an agent to call it correctly.

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

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

Schema coverage is 100% for the single parameter 'reference' with a description of 'CanadaBuys or Alberta APC reference number'. The tool description repeats 'for one opportunity' but does not add any new semantic detail about the parameter (e.g., format or validation). Baseline of 3 is appropriate as the schema fully documents the parameter.

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 a specific verb (assess) and resource (bid/no-bid checklist for one opportunity), and lists the evaluation criteria. It is unambiguous and unlikely to be confused with sibling tools, though it does not explicitly name a sibling to differentiate from.

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 for a single opportunity ('for one opportunity') but provides no explicit guidance on when to use this tool versus alternatives like daily_bid_brief or get_opportunity_details. No exclusions or alternative-referencing is present, leaving the agent to infer selection.

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

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

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond annotations: it is 'free', 'daily', pulls from CanadaBuys and Alberta APC, and the profile is per-call (inline). This informs the agent that no persistent profile is used, which is valuable for expected behavior.

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

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

Two short sentences, front-loaded with the core purpose and followed by the key usage instruction. Every word earns its place; no filler or redundancy. The structure is efficient and 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 read-only tool with 100% schema coverage, the description covers the core purpose and the key behavioral nuance (inline profile). It does not describe the output format or sections, but given no output schema and the straightforward nature of a 'brief', it is sufficiently complete for an agent to invoke correctly. A minor gap is not explaining how days/limit affect the output, though the schema covers them.

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. The description mentions passing an inline profile 'per call', but this is already stated in the schema's profile field description ('used for this call only'). The description does not add extra meaning for days or limit beyond what the schema provides, so it does not exceed the 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 states a specific action ('Generate') on a specific resource ('a free daily bid brief') with explicit data sources (CanadaBuys and Alberta APC). This clearly distinguishes it from sibling tools like search_opportunities or find_matching_opportunities, which are search-oriented rather than brief-generation 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 description implies usage for generating a daily brief and mentions it is for a business profile, but it does not explicitly contrast with alternatives or state when not to use this tool. It gives some context (free, daily, from specific sources) but lacks explicit routing guidance among the many 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?

Annotations already mark this as read-only and non-destructive, and the description does not contradict them. It adds profile-scoped behavior and 'per call' semantics, but says nothing about matching logic, ordering, or output shape, so behavioral transparency is adequate rather than rich.

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 purpose and then a single actionable instruction. No filler or redundant restatement of the title.

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

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

The schema and annotations fill in the read-only profile and parameter details, and the tool is a simple list/find operation. However, without an output schema the return shape is left implicit, and the description never addresses what happens when no profile is supplied or how this differs from the many sibling search tools; that is a moderate completeness 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 input schema has 100% description coverage, including nested profile field semantics such as 'derived from description when omitted' and 'overrides any saved profile.' The description only reiterates that an inline profile should be passed, adding no new parameter 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?

The description opens with a specific verb ('Find'), a specific resource ('Alberta Purchasing Connection opportunities'), and a selection criterion ('match your business profile'), so an agent understands exactly what the tool returns. It does not explicitly contrast with similarly named siblings such as search_alberta_opportunities or find_matching_opportunities, though the resource and 'business profile' framing narrow the purpose.

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

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

The description establishes the use case: finding Alberta Purchasing Connection opportunities relevant to a business profile, and instructs the caller to pass an inline profile. It lacks explicit when-not-to-use or alternative routing (e.g., saved profile vs search_alberta_opportunities), but the context is clear enough for a matching task.

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 profile is 'inline' and 'per call only', and notes the public endpoint behavior without a subscriber key. This adds useful context beyond 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?

Two sentences with zero waste. The main action is front-loaded, and the critical usage note about the inline profile is included in the second sentence.

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 tool has an output schema, so return values are covered. The description explains the core matching behavior and the profile mechanism. It could be more explicit about ranking criteria or how the profile is used, but the schema and annotations cover most operational needs.

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 parameters thoroughly. The description adds the key context that the profile is 'inline' and 'per call only', which is valuable, but doesn't add much beyond what the schema already states.

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 a specific verb ('Rank') and resource ('CanadaBuys and Alberta APC opportunities') against a business profile. It distinguishes itself from sibling tools like find_opportunities and find_alberta_opportunities by focusing on ranking/matching against a profile rather than simple searching or 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?

The description implies the tool is for matching opportunities to a business profile, and the profile parameter description clarifies it's for per-call use, overriding any saved profile. However, it doesn't explicitly state when to use this vs. alternatives like find_opportunities or search_opportunities, nor when not to use it.

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

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

Annotations already mark this as a safe read-only operation, and the description adds useful behavior: opportunities are scored/ranked and include explanations for fit, and the profile is per-call inline. There is no contradiction and no hidden side effects to disclose.

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, each earning its place: what the tool does, what it returns, and how to provide context. Key info is front-loaded.

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 tool with no required parameters and a self-contained schema, the description covers the essential behavior and return characteristics. It doesn't fully spell out what happens when profile is omitted or how scores are scaled, but the schema's profile description already notes saved-profile override, so this is largely 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 days, limit, and each profile field. The main description adds little beyond reaffirming that profile is passed inline, 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?

The description names a specific resource ('government contracts') and a clear operation ('find... that match your business profile'), plus the distinctive outputs (scored and ranked opportunities with explanations). It doesn't explicitly call out how it differs from the very similarly named find_matching_opportunities or search_opportunities, so it stops short of full sibling differentiation.

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 clearly says to pass an inline profile per call, which tells the agent how to invoke it and implies this is the right tool when matching against a business profile. It does not state when not to use it or name an alternative, but the context is unambiguous enough.

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 and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context such as response format, record coverage, or error conditions, beyond restating that it returns full 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?

Single sentence with no filler, front-loaded verb, and no redundant restatement of the title. Every word adds 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 one-parameter read-only lookup, the description is essentially sufficient: it names the identifier and the expected result ('full details'). However, with no output schema, it leaves the exact returned fields unspecified, 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 description coverage is 100% and the description repeats the schema's wording ('Reference or solicitation number') without adding examples, formats, or edge-case guidance. Baseline of 3 applies because the schema carries the 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 clear verb ('Get'), specific resource ('full details of a contract'), and the exact lookup key ('reference or solicitation number'). This distinguishes it from search-based siblings like search_contracts and summarize_contracts without needing to open 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 implies the tool should be used when a reference or solicitation number is in hand, but does not explicitly state when to prefer this over alternatives or how to obtain the identifier (e.g., via search_contracts). No exclusions or fallback guidance is provided.

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, and the description adds the context that the returned data is the current profile used for matching. For a zero-parameter read operation this is adequate, though no additional behavioral specifics (e.g., staleness, auth, empty profile behavior) are disclosed.

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

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

One compact sentence with no filler. The key facts (view action, profile resource, matching-contract purpose) are front-loaded and every word 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 parameterless read-only tool with annotations covering safety and no output schema, the description supplies the necessary purpose and context. There is no missing information that would prevent an agent from invoking it correctly.

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

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

The input schema has zero parameters, so schema description coverage is complete and there is nothing for the description to add. Per the 0-parameter baseline, this is a clean score; the description reinforces that no inputs are 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 ('View') and specific resource ('your current business profile') and adds purpose ('being used to match contracts'). This clearly distinguishes it from the write-oriented sibling set_business_profile and other opportunity/contract 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 phrase 'being used to match contracts' implies the tool is appropriate when an agent needs to inspect the active matching profile, but there is no explicit when-to-use versus alternatives or exclusion criteria. The alternative set_business_profile is never referenced, 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. 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 readOnly and non-destructive, so the description does not need to restate that. The description adds that it lists opportunities 'closing soon', implying some temporal filtering, which is useful context. However, it does not disclose details like pagination behavior or that results are combined across two sources (CanadaBuys and Alberta APC), which could be important for agent expectations. Given the annotations, a 3 is appropriate as it adds minimal but some context.

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

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

The description is a single sentence with no filler: 'List CanadaBuys and Alberta APC opportunities closing soon.' It is appropriately sized for a simple listing tool, and the key scoping info (sources and temporal filter) is front-loaded. Every word earns its place, and it is easy to parse quickly.

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 an output schema (as indicated by context signals), the description doesn't need to explain return values. The schema fully documents parameters, and annotations cover behavior. The description provides the essential purpose and scope. The only minor gap is not explicitly mentioning that it fetches from two sources (CanadaBuys and Alberta APC) as a combined list, but that's implied by the description. For a simple read-only listing tool, this is largely 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?

The schema provides 100% description coverage for all 5 parameters, each with clear descriptions for days, limit, source, category, and province. The description doesn't add any extra meaning beyond what the schema already has, such as clarifying that 'days' uses today as the reference or that 'source' has specific format ('all', 'federal', 'alberta'). With full schema coverage, the baseline is 3, and the description adds no value beyond the schema.

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

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

The description clearly states the resource ('CanadaBuys and Alberta APC opportunities') and the action ('closing soon'), which is specific and distinct from siblings like find_opportunities or search_opportunities. However, it doesn't explicitly differentiate from list_alberta_deadlines or list_upcoming_deadlines, though the mention of specific sources helps. Overall, it's clear but could be more explicit about what distinguishes it from similar listing tools.

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

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

The description implies usage for filtering by time to closing, but does not provide explicit guidance on when to use this tool versus siblings like 'find_opportunities' or 'list_alberta_deadlines'. There is no mention of alternatives or exclusions, so an agent might not know if this is the best choice for a general search vs. deadline-specific queries. The brevity leaves usage context to be inferred.

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, covering the safety profile. The description adds no additional behavioral context beyond 'list,' such as pagination, sorting, or scope limitations. Since annotations cover the read-only nature, the description is adequate but does not enhance transparency beyond that.

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, direct sentence with zero filler. It is front-loaded with the core action and resource, and every word earns its place. There is no wasted space 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 simple read-only listing tool with two well-documented parameters and no output schema, the description is complete enough. The agent can infer the behavior from the description and schema. However, it does not clarify what 'upcoming' means beyond the 'days' parameter (which the schema covers), and it doesn't mention any ordering or filtering defaults beyond what the schema provides. Still, given the low complexity, it is sufficient.

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% (both 'days' and 'province' have descriptions), so the schema already documents the parameters. The description does not add any extra meaning or usage details for the parameters; it relies entirely on the schema. Baseline 3 applies because the schema carries the load.

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 clear verb and resource: 'List contracts with upcoming closing deadlines.' It is not a tautology, and it gives the core action. However, it does not differentiate from sibling tools like list_deadlines or list_alberta_deadlines, which likely serve similar purposes, so it lacks sibling differentiation.

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 guidance on when to use this tool versus its many siblings (e.g., list_deadlines, list_alberta_deadlines, daily_bid_brief). There is no mention of context, exclusions, or alternatives, leaving the agent to infer when this specific tool is appropriate.

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, covering safety. The description adds behavioral context beyond annotations by specifying output ordering (by closing date) and included fields (days remaining, notes), which helps the agent anticipate the result format. It doesn't mention pagination or limits, but this is minor for a simple read-only list.

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, efficient sentence that front-loads the verb and resource, followed by relevant output details. No wasted words; every element 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?

With no output schema, the description serves as the sole source of return information. It conveys the list nature, sorting, and key fields (days remaining, notes), which is sufficient for an agent to understand the output. It omits details like whether it returns full opportunity objects or just summaries, but for a watchlist view this is acceptable 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?

There are zero parameters, so the schema fully covers parameter semantics. The description doesn't need to explain parameters; it correctly focuses on output behavior. Baseline 4 for no-parameter tools is appropriate.

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

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

The description states a specific verb ('List') and resource ('watched opportunities'), and adds concrete details (sorted by closing date, days remaining, notes) that clearly distinguish it from sibling list tools like list_deadlines or search_opportunities. The purpose is unambiguous.

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

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

The description implies a clear use case—when the user wants to view their watchlist—but does not explicitly mention alternatives or when not to use this tool. It lacks guidance on choosing between this and other listing tools, though the name and context make the primary use evident.

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 known. The description adds valuable context about the E2B sandbox usage, the conversion pipeline (Cohere Parse to markdown), and the review by Command A+. This goes beyond the annotations by explaining the internal process, though it doesn't detail side effects or return format.

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, efficient sentence that front-loads the core action ('Use an E2B sandbox to process tender attachments') and then elaborates on the processing steps. There is no wasted wording, and the key information is immediately clear.

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 tool has 6 parameters, a nested object, and no output schema. The description is brief and does not explain what the tool returns or what the output looks like. Since there is no output schema, the description should clarify the result of processing (e.g., the markdown or review output), but it only says 'reviews the evidence' without specifying the deliverable. This leaves a gap for an agent deciding whether the tool meets its needs.

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%, meaning all parameters are already documented in the schema. The description adds no extra meaning beyond what the schema provides—it merely mentions processing attachments, which is implied by the tool name and schema fields like max_attachments. Since the schema does the heavy lifting, a 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 clearly states the tool's function: it processes tender attachments using Cohere Parse to convert PDF/image files to markdown and then Command A+ reviews the evidence. This is a specific verb+resource with a detailed pipeline, distinguishing it from siblings like analyze_contract_with_cohere which focus on analysis rather than processing attachments.

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 guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or comparisons to sibling tools. While the purpose is clear, the agent is left to infer when this processing tool is appropriate, which is a significant gap.

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

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

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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds domain context ('from Alberta public-sector buyers') but does not disclose return behavior, pagination, or result ordering. It does not contradict 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 a single, front-loaded sentence with no filler. It states the essential purpose efficiently and 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?

Given the simple schema and strong annotations, the description is minimally adequate for invoking the tool. However, it lacks return-format details and does not clarify how this tool differs from similarly named siblings, which is important for correct tool selection in a crowded toolset.

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 four parameters and their defaults. The description adds no additional meaning beyond the schema, which matches the baseline expectation for fully covered parameters.

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 ('Search') and the resource ('Alberta Purchasing Connection opportunities from Alberta public-sector buyers'). It is specific about the domain, but it does not distinguish itself from the sibling tool 'find_alberta_opportunities', which appears to target the same resource.

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 no guidance on when to use this tool versus alternatives such as 'find_alberta_opportunities', 'search_opportunities', or 'find_opportunities'. There is no mention of preferred use cases, exclusions, or relationships to sibling tools.

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 safety with readOnlyHint=true and destructiveHint=false, so the bar for behavioral disclosure is lower. The description adds the search scope and filter options but does not describe result format, pagination, or open-world behavior; it also mentions a 'status' filter that is not present in the schema.

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

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

The description is compact and front-loaded, with the main action in the first sentence. The only issue is the inaccurate 'status' mention, but structurally it is appropriately 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?

For a simple read-only search tool with fully documented parameters, the description is mostly adequate. However, it omits guidance on how this search relates to sibling search tools and contains a phantom status filter, which leaves some context incomplete.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description actually undermines the schema by claiming filtering by 'status' is possible when no status parameter exists. It adds no meaningful information beyond the schema's parameter descriptions.

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 searches Canadian federal government contracts and lists concrete filters. It distinguishes itself from siblings like search_alberta_opportunities through the federal scope, though it does not explicitly name alternatives.

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

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

There is no guidance on when to use this tool versus the many sibling search tools, such as search_opportunities or search_alberta_opportunities. The federal-contract scope is implied but no explicit when-to-use or when-not-to-use conditions are provided.

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 description does not need to repeat safety. It adds the behavioral fact that the search spans two sources simultaneously, which is useful context. However, it does not disclose details like result merging, pagination, or any side effects, but given the annotations cover the safety profile, a mid score is appropriate.

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 that delivers the essential purpose without any filler. It is optimally concise and well-structured for an agent to quickly grasp the tool's function.

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 presence of a rich output schema and 100% parameter coverage, the description only needs to convey the high-level intent, which it does. However, it omits any note about how results from the two sources are combined (e.g., deduplication, ordering) or any default behavior. For a tool with moderate complexity, this is adequate but not exhaustive, so a 3 reflects the minimal 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?

The input schema has 100% coverage for all five parameters, each with descriptive text. The description adds no parameter-specific meaning beyond the schema. Per calibration, with high schema coverage the baseline is 3, and there is no additional value from the description, so 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?

The description clearly states a specific action ('search') applied to two named resources ('CanadaBuys and Alberta Purchasing Connection') together. This distinguishes it from sibling tools like search_alberta_opportunities or find_opportunities, which likely target one source or a different scope. It is not a tautology and directly conveys the tool's core purpose.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It implies a combined search but does not state conditions like 'use when you want results from both federal and provincial sources' or contrast with tools like search_alberta_opportunities or find_opportunities. The agent is left to infer usage from the wording 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 indicate destructiveHint=true, but the description does not disclose that saving may overwrite the existing profile or that it is a write operation. It adds no context about data replacement or confirmation. It does not contradict the annotations, but it fails to add value beyond the schema and annotation hints.

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 only two sentences and is appropriately concise. It front-loads the user-facing instruction ('Tell me about your business') and then states the outcome. It avoids unnecessary fluff, though it could be more specific about the action and side effects.

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 mutation with three parameters and no output schema, the description is mostly adequate. However, given the destructiveHint annotation, it should warn that the profile will be overwritten. It also does not mention whether the profile is saved immediately or requires additional steps. These are minor gaps but not critical for a straightforward 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%, so all three parameters (location, description, company_name) are already documented. The description adds no additional meaning or constraints beyond what the schema provides. It does hint at the purpose of the description field ('What does your business do?') but that is already in the schema.

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

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

The description states a clear action ('save your profile') and its purpose (use it to find matching contracts). It distinguishes from the sibling get_my_profile, which is for retrieval. However, it doesn't explicitly say that it updates or overwrites the existing profile, so it's not fully specific about the resource effect.

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 the tool is for initial setup or updating a business profile before searching for contracts, but it does not explicitly state when to use it versus alternatives like get_my_profile or when to re-run it. There is no mention of prerequisites or exclusions.

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 this a safe, read-only, non-destructive operation, and the description is consistent with them. The description adds only the 'summary' output form and not details like the shape of results, what 'available' means, or response size, but the zero-parameter read-only nature keeps the gap modest.

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 sentence with no filler and the action is front-loaded. For a zero-parameter tool, this length is appropriate.

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 short description, the tool's result contents and scope are underspecified. The phrase 'available contracts' is ambiguous, and given many similar siblings, the definition does not give an agent enough context to reliably select 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?

There are zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. The 0-param baseline of 4 applies.

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

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

The description names a clear action ('Get') and object ('a summary of available contracts'), so the basic purpose is understandable. However, 'available contracts' is vague and the description does not distinguish this tool from siblings such as search_contracts, get_contract_details, or summarize_alberta_opportunities; the 'federal' scope only appears in the title.

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 offers no guidance on when to choose this tool over alternatives. It does not mention that search_contracts or get_contract_details should be used for filtered or detailed lookups, nor does it exclude Alberta-specific cases; selection is left entirely to inference from the name.

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 destructiveHint=true and readOnlyHint=false, so the mutation nature is known. The description adds the useful context that only watchlist membership is affected, not the opportunity itself. It does not disclose additional behaviors such as idempotency or behavior for an unknown reference, but the main destructive trait is covered.

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 one tight sentence that front-loads the action and includes no filler. It is slightly redundant with the title, but remains efficient and easy to parse.

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 one-parameter tool with clear annotations and no output schema, the description provides the essential what and how. It does not describe response behavior or edge cases, but those are not critical for a straightforward watchlist removal operation.

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 covers the single parameter 100% with 'Reference number to stop tracking', so the description does not need to add much. The phrase 'by reference number' only repeats the schema and adds no format, source, or validation detail. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Remove'), a specific resource ('an opportunity from the watchlist'), and the method ('by reference number'). It is clearly distinguishable from siblings like watch_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?

The description gives no explicit guidance on when to use this tool versus watch_opportunity or list_watchlist. There are no criteria, prerequisites, or exclusions; the inverse relationship to watch_opportunity is only implied by the name and title.

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 indicate readOnlyHint=false and destructiveHint=false, and the description adds useful behavioral context: the watchlist is persistent and the note is optional. There is no contradiction, though duplicate handling or confirmation responses are not disclosed.

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 no filler. It identifies the action, the resource, the persistence characteristic, and the optional note in minimal words.

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

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

For a simple two-parameter tool with full schema coverage and annotations, the description is sufficient for an agent to invoke it correctly. It does not cover duplicate additions or idempotency, but that is not critical for an add-to-watchlist operation.

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 both 'reference' and 'note' already documented in the input schema. The description does not add new parameter-level meaning beyond the watchlist context, so the baseline of 3 applies.

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

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

The description states a specific verb ('Add'), a specific resource ('CanadaBuys or Alberta APC opportunity'), and a clear target ('persistent watchlist') with an optional note. This cleanly distinguishes the tool from sibling 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?

The description gives helpful context by restricting the tool to CanadaBuys or Alberta APC opportunities and mentioning the watchlist is persistent, but it does not explicitly say when to use this tool instead of alternatives or when not to use it. Usage is implied rather than directly guided.

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