Investboard

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

Beyond the annotations (readOnlyHint false, destructiveHint true, idempotentHint false), the description explains that each call saves a new check in the investor's history, which justifies the non-idempotent hint, and that stale or missing data yields an 'unavailable' verdict with recovery guidance. It also clarifies that no order is ever transmitted, materially reducing the destructive-write risk perception.

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 verdict vocabulary is front-loaded and each sentence adds facts (saved check, check_id, staleness handling, no order transmission). It is dense but slightly long, with some phrasing that could be tightened.

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 complex mutation tool with 7 parameters and an output schema, the description covers verdicts, saved-check behavior, evidence freshness and stale-data handling well. Gaps remain around setup_id and rationale, which are unexplained in both schema and text.

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 schema coverage at only 14%, the description compensates by explaining the two accepted shapes for 'legs' (ISIN/asset class with EUR or percent amounts) and the single asset-class alternative form. It leaves setup_id, rationale and the action_type enum semantics undocumented, so the coverage gap is only partially filled.

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: 'Check an intended change against the connected investor's mandate and return a rule-level verdict', and enumerates the possible verdicts. An agent can distinguish this from siblings like get_policy or record_decision 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?

Usage is implied rather than specified: the agent should call it to pre-check a change, and the note 'Investboard never places, changes or transmits an order' bounds the scope. However, no explicit when/when-not or named alternative (e.g. record_decision for the follow-up step) 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?

Goes well past the readOnly/idempotent annotations: discloses that no instrument names are returned, that journal text is verbatim investor record rather than assistant opinion, that a verdict contains only conclusion and date, that an unrecognized before_id marker yields an empty page that is not the end of the journal, and what reviews_due_only actually filters on.

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?

Purpose and core behavior are front-loaded, and nearly every sentence carries operational content (pagination, empty-page pitfall, verdict scope, review workflow). It is dense and clause-heavy, though, so the middle section requires careful parsing rather than skimming.

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 described, and the description still covers the non-obvious response characteristics (no instrument names, partial verdict content) plus the review workflow and pagination edge cases. Nothing needed to call 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 coverage is only 50%, and the description compensates for the two undocumented params: before/before_id resume semantics plus the warning to pair them, and a precise definition of reviews_due_only (review date arrived, no verdict, backing thesis still active on that version). The limit parameter is never mentioned in the description, so semantics there rest solely on the schema's min/max bounds.

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 ('Read the investor's own decision journal') and enumerates exactly which fields come back (memo, falsifier, conviction, mood, review date, verdict, originating check). It also draws the boundary with get_reflection_history, so an agent can distinguish it from siblings without opening schemas.

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

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

Gives concrete trigger conditions ('when the investor asks what they decided or wrote, or when a review is due'), names the alternative for reflection data and instructs 'do not infer relationships from matching dates or text', and states an exclusion ('cannot write a journal or review').

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 the tool is read-only, idempotent, non-destructive, and closed-world, and the description adds substantial behavior beyond that. It explains resolved=false, ambiguous matches, gated Premium entitlement, the specific absence signal, subject identifier echoing, current-projection versus historical-version semantics, and open verdict 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?

The description is long, but it is front-loaded with purpose and usage, then organized around distinct edge-case rules. Most sentences carry unique behavioral information, though some return-state detail may overlap with the output schema.

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 read-only annotations and the presence of an output schema, the description is largely complete for correct invocation and interpretation. It explicitly covers ambiguous, gated, and absent-record states, but leaves exchange parameter semantics under-specified.

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 only 33%, so the description must compensate. It does clarify that identification can be by ISIN or by ticker with an optional exchange, but it does not explain exchange value semantics, precedence when both ISIN and ticker are supplied, or how ticker and exchange interact for matching.

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: read the investor's own recorded investment thesis for one instrument. It also specifies the identifying modes (ISIN or ticker with optional exchange) and the substantive content returned (statement, falsifier, dates, conviction, verdict), which clearly separates it from siblings such as get_journal or get_reflection_history.

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

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

It gives clear usage context: recalling the investor's premise before discussing their own recorded instrument, or when the investor asks what they thought. It does not name alternatives or explicitly state when not to use this tool, so it falls short of full routing guidance.

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

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

Annotations declare readOnlyHint=false, which would otherwise be puzzling for a 'read' tool; the description resolves this by explaining that supplying setup_id records the read and binds the receipt, while explicitly not changing the mandate. It also discloses chunk-consistency, signature-over-whole-document, and snapshot-restart semantics — real behavioral context beyond the annotations. Minor gaps are the return shape and any rate/permission limits.

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

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

The purpose is front-loaded and the paragraph is dense but purposeful — nearly every clause (pagination, signature scope, snapshot restart, setup_id binding) conveys a distinct fact. A couple of sentences, such as the investor-authored originals note, are terse to the point of ambiguity, keeping it from a 5.

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

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

With an output schema present, return values needn't be explained, and the description still covers pagination, signature integrity, and the setup_id side effect. The unexplained `max_characters` bound and the obliquely-referenced offset are the only meaningful omissions for a 4-parameter tool.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains `setup_id` thoroughly and effectively documents `offset`/`document_sha256` via the pagination instructions, but `max_characters` is never mentioned and the offset param is only referred to obliquely through response field names (page.next_offset), which is a notable gap at 0% coverage.

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 opening sentence gives a specific verb (`Read`) and concrete resources (the signed original mandate or the structured policy export) in Markdown form. An agent can immediately tell this is the document-retrieval tool. It stops short of naming any sibling to distinguish itself from, so it lands at 4 rather than 5.

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

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

It gives clear in-tool usage (page with `page.next_offset` + `page.document_sha256` until null, then concatenate) and notes setup_id is optional and doesn't change the mandate. But there is no guidance on when to choose this over siblings like `get_own_record` or `get_portfolio_holdings`, so usage context is implied rather than stated.

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

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

Although annotations already declare a safe read-only operation, the description adds substantial behavioral context beyond them: consent and entitlement requirements, incomplete valuation behavior, unresolved identity and opaque sleeve limitations, and the fact that no default issuer cap is applied as an investor rule.

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 dense but front-loaded, leading with what is read and immediately following with usage context. Every sentence carries relevant caveats or scope information, though it is longer than strictly necessary for some readers.

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

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

With an output schema present, the description need not explain return values. It covers the important caveats an agent needs: denominators and coverage for weights, limitations from missing constituents and unresolved identities, withholding behavior under incomplete valuation, and required consent/entitlement.

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 are no parameter semantics to document. The baseline for a parameterless tool is 4, and the description appropriately does not invent parameter details.

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: reading canonical whole-portfolio exposure dimensions, issuer concentration, and shared fund holdings. It also distinguishes the scope from sibling tools by clarifying that overlap is not historical correlation, which helps separate it from get_portfolio_correlations.

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

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

It gives clear usage context: 'Use to explain concentration, diversification and fund overlap.' It also implicitly distinguishes overlap analysis from correlation analysis. However, it does not explicitly say when not to use it or name the sibling holdings/correlations tools as 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?

Goes well beyond the annotations: discloses the return contents (sample dates, weeks, pair observations, confidence intervals, price-only exceptions, exclusions, covered value share), states a no-inference guarantee ('never infers a numeric correlation from allocations or holdings'), documents the unavailable failure mode, and specifies required consent/entitlement. This is rich behavioral context for a read-only tool.

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

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

Front-loaded with the core purpose and use case, then supporting behavioral detail. Dense but each sentence carries information (returns, guarantees, failure mode, auth). Slightly long, but none of it is wasted 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 4-param read tool with an output schema, this is complete: it covers what is returned, the no-inference guarantee, auth/entitlement requirements, the unavailable path, and pagination continuation. An agent has everything needed to call it correctly and interpret edge cases.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning to `window` ('requested historical window') and `computed_at` ('Send computed_at on further pages'), effectively documenting the pagination cursor. However, `limit` and `offset` are never explained beyond the vague 'further pages' hint, leaving half the parameters undocumented.

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: 'Read measured historical weekly EUR return correlations' from the canonical correlation-lens observation. It separates itself from the closest sibling by noting it is 'for how held investments moved together... not constituent overlap', so an agent can distinguish it from holdings/analysis tools without opening schemas.

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 frames the use case ('how held investments moved together over the requested historical window') and an exclusion ('not constituent overlap'). It also states entitlements/consent needed to invoke. It stops short of naming a sibling alternative tool by name, but the when/when-not framing is clear.

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 past the annotations (which already declare read-only, idempotent, closed-world): it discloses the required portfolio:read consent and portfolio-detail entitlement, the snapshot/pricing/constituent date stability contract, the computed_at re-pagination and restart-on-snapshot-change rule, and that missing snapshots return unavailable with no fabricated analytics. That is exactly the operational context an agent cannot get from structured 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?

Purpose and the critical non-additivity warning are front-loaded, and nearly every clause carries unique information. The middle sentence ("Preserve the snapshot base currency, pricing and constituent dates, unknown mass, coverage and denominators") is telegraphic and packs three distinct contracts into one dense string, costing some readability.

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 spelled out, and the description nonetheless covers access prerequisites, snapshot consistency, pagination continuation, and the empty/unavailable case. For a read-only paginated tool with 4 optional params, nothing an agent needs to invoke 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 0%, so the description must carry parameter meaning. It explains view indirectly (alternative views, never additive) and computed_at thoroughly (send on further pages, restart if snapshot changes), but says nothing about limit/offset semantics or the enum default. Partial compensation only.

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

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

States a specific verb (read) and resource (direct holdings / pooled fund look-through positions) scoped to the connected investor's imported accounts. The direct-vs-look-through distinction is clearly drawn, though it never names the sibling analysis tools (get_portfolio_analysis, get_portfolio_correlations) it most needs to be separated 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?

"Use for what the investor owns and shared direct/indirect exposure" gives a clear selection context, and "These are alternative views of the same capital, never additive" is an unusually valuable usage warning that prevents double-counting. No explicit when-not-to-use or named alternative tool, which keeps it below a 5.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses that paging requires following BOTH returned cursors, that Investboard-originated checks are absent from results, that outcomes are investor-reported and never establish execution, that saved verdicts keep original evidence dates, and that linked_decision is computed on read and never stored. These are substantive behavioral facts an agent could not infer from annotations alone.

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?

Purpose is front-loaded in the first sentence, followed by usage, paging, and scope caveats in a logical order. The final sentence on linked_decision is long and heavily qualified ('never an instrument and never a value'), which is partly redundant given an output schema exists, but it still carries non-obvious derivation semantics.

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 four optional parameters, full annotations, and an output schema, the description covers scope, paging discipline, and confidence semantics well. Minor gaps remain: default ordering, whether id is an exclusive filter or combinable with cursors, and the meaning of 'limit' are not addressed.

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

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

Schema coverage is only 25% (only id is documented), so the description must compensate — and it does for the paging pair: 'before' and 'before_id' are revealed as two returned cursor values that must be followed together. 'id' semantics are reinforced via agent_reflection_id. 'limit' and the exact cursor ordering remain undocumented in either place.

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: list the longitudinal audit of actions checked by an assistant plus their verdicts, scoped to the connected user. That is clearly distinct from the mutating sibling check_action and from get_journal, and the mention of 'agent_reflection_id' from a journal entry links the two resources. It stops short of explicitly naming a sibling it must not be confused 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?

'Use id to read the check named by a journal entry's agent_reflection_id' gives a concrete trigger condition, and 'Follow both returned cursor values when paging' tells the agent how to continue. The exclusion 'Checks made in Investboard itself are not listed' bounds expectations. No explicit when-not-to-use versus check_action is 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that: a hard cap of three drivers, exactly one attention item surfaced (with a link), and a staleness signal about the underlying evidence — all of which affect how an agent should interpret the response.

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 the core purpose, with the scope exclusion last. The middle sentence is a dense enumeration of payload contents that overlaps with the existing output schema, which is the only mild 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?

An output schema exists, so return values need not be spelled out, and the annotations plus the explicit scope boundary cover the rest. The 'Mirrors the Mein Mandat page' reference assumes product familiarity but does convey UI parity, so nothing an agent needs in order to call 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?

The tool takes zero parameters, so the baseline is 4. The description's remark that it 'names no instrument and no valuation' usefully confirms there is nothing to scope by, consistent with the empty input 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?

States a specific verb ('read') and a specific resource ('where the mandate stands'), then enumerates exactly what the reading contains: plan state and severity, up to three drivers, the single attention item with a link, and evidence freshness. It also draws a boundary against sibling tools ('names no instrument and no valuation'), so an agent can separate it from get_portfolio_analysis, get_portfolio_holdings and get_own_record 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?

The scope statement ('names no instrument and no valuation') plus 'mirrors the Mein Mandat page' tells an agent this is the top-level summary read, not an instrument-level drill-down, which implicitly routes detail requests to the portfolio siblings. It does not explicitly name an alternative tool or state when not to use it, so it falls short of a 5.

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

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

'Write-once per check' is real behavioral disclosure beyond the annotations: a repeat call will not overwrite, which an agent needs in order to avoid treating this as an update path. The explicit disclaimer that no order is placed/changed/transmitted adds safety context the destructiveHint annotation alone does not convey. It omits what an agent should expect on a second attempt (error vs. silently ignored) and does not mention that records cannot be removed.

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

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

Three short sentences, front-loaded with what gets written, then the write-once constraint, then the safety disclaimer. Every sentence adds information; nothing repeats the title or schema.

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

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

With an output schema present, return values need no explanation, and the description covers the essential traits: mutation, write-once, no order side effects. It leaves open what happens when the check_id does not exist or a decision was already recorded, which matters for a non-idempotent write.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it partially does: it enumerates the three outcomes, marks the note and broker reference as optional, and implies the check linkage. It never mentions check_id as a required UUID identifying which check the decision attaches to, nor the length bounds, so the highest-value required parameter is left to the schema alone.

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 (record a decision) plus the exact domain of values (proceeded, abandoned, deferred). The closing sentence sharply distinguishes it from any order-execution capability and, implicitly, from the read-only siblings such as get_journal or check_action.

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?

'Record what the investor decided after a check' gives clear timing context: call it after a check exists. The exclusion ('never places, changes or transmits an order') rules out a tempting misreading. It does not name a sibling alternative or state what to do if the decision is later revised, 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.