Skip to main content
Glama

Check an intended change

check_action
Destructive

Check an intended change against the connected investor's mandate and return a rule-level verdict: ok, breach, cooling_off, no_rule, unavailable or unclassified. Accepts legs, each naming an ISIN or an asset class with an amount in euros or in percent of the portfolio; a single asset-class action (action_type, asset_class, amount_pct_of_portfolio) is also accepted. Every touched rule includes its current and projected state, plus evidence coverage and freshness. The verdict cites asset classes, the investor's rules and leg indices, never an instrument name. Each call saves a new check and verdict in the investor's history and returns its check_id, the identifier for that saved record. Stale or missing portfolio data produces an unavailable verdict with evidence recovery guidance and an optional next_step_href relative to the connected Investboard origin. A repeated call evaluates the then-current evidence and creates another saved check. Investboard never places, changes or transmits an order.

Input Schema

NameRequiredDescriptionDefault
legsNo
fundingNoWhere the money for the buy legs comes from. within_book (the default): the book keeps its size and each leg moves only its own class, so a purchase paid from cash names its cash side as a sell leg of its own. new_money: money from outside the book, so the book grows by the buy legs; every class and position share is measured over the grown book, and an issuer's share over the equity book grown by the equity buys. The action_type does not set it: a contribute action is measured within the book unless funding is new_money.
setup_idNo
rationaleNo
action_typeYes
asset_classNo
amount_pct_of_portfolioNo

Output Schema

NameRequiredDescriptionDefault
statusYes
reasonsYes
check_idYesUse this saved check id in record_decision or get_reflection_history.
coverageYes
checked_atYes
unlocks_atYes
cited_bandsYes
cited_rulesYes
next_step_hrefYes
schema_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources