Skip to main content
Glama

Assess portfolio risk

risk_assess
Read-onlyIdempotent

Measure a portfolio you state against limits you state, on official point-in-time prices.

    Reports concentration and peak-to-trough drawdown, and NAMES every position it could not
    price rather than quietly assessing the rest — an assessment covering 60% of a portfolio
    without saying so is worse than none.

    Any breach produces a PROPOSAL (e.g. "reduce 2330") that requires a human decision.
    Approving a proposal records that decision; it executes nothing. TWMD has no order path.

    Args:
        positions: `[{"ticker": "2330", "quantity": 100}, ...]`. YOUR stated holdings — nothing
            is read from a brokerage account, because no such connection exists.
        as_of: knowledge cutoff, `YYYY-MM-DD`. Defaults to the latest available data.
        max_position_weight: single-name limit as a fraction (0.35 = 35%).
        max_drawdown: peak-to-trough limit as a fraction (0.25 = 25%).
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNo
positionsYes
max_drawdownNo
max_position_weightNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNo
errorNo
caveatNo
limitsNo
reasonNo
statusNo
blockedNo
weightsNo
coverageNo
findingsNo
reliableNo
executionNo
max_drawdownNo
portfolio_valueNo
proposed_actionsNo
not_investment_adviceNo

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses significant behavior: it names unpriced positions instead of silently assessing a partial portfolio, breaches produce proposals that require human decisions, approving a proposal records the decision and executes nothing, TWMD has no order path, and pricing is point-in-time official data. This is far richer than annotation-only disclosure.

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

Conciseness5/5

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

The description is front-loaded with purpose, uses compact paragraphs and labeled Args, and every sentence adds functional value. The caveats about unpriced positions and the no-order-path behavior are important, not padding.

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

Completeness5/5

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 rebuild the return structure. It covers input formats, defaults, key behavioral caveats, the proposal/approval workflow, and the lack of brokerage integration, giving an agent enough to invoke the tool correctly in context.

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

Parameters5/5

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 and succeeds. It gives the exact positions format with an example, clarifies these are user-stated holdings, defines as_of as a YYYY-MM-DD knowledge cutoff with default behavior, and explains max_position_weight and max_drawdown as fractions with concrete examples.

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 first sentence states a specific verb ('Measure'), a specific resource ('a portfolio you state'), and the conditions ('against limits you state', 'on official point-in-time prices'). It clearly conveys what the tool does and implicitly distinguishes it from account-level risk reads by emphasizing user-supplied holdings.

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

Usage Guidelines4/5

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

The description gives clear context for when to use it: for assessing a stated portfolio against stated limits, with an explicit warning that nothing is read from a brokerage account because no connection exists. It does not mention sibling tools by name or give explicit when-not-to-use conditions, so it stops 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

The tools are largely distinct: querying, searching, backtesting, risk reads, alerts, memory, and audit functions each have clear homes. A few adjacent pairs (risk_read vs risk_assess, company_health_check vs positioning_read) could be confused, but the descriptions draw explicit boundaries.

Naming Consistency3/5

There are strong consistent clusters like list_*, get_*, run_*, and memory_*, but the *_read suffix alternates with noun-first names like company_health_check, and bare-verb tools like ask, calendar, chart, and screen break the pattern. The naming is readable but not uniform.

Tool Count2/5

Forty tools is well past the 25+ threshold and makes the surface heavy for an agent to navigate, even though the breadth reflects a genuinely wide platform. Several clusters could plausibly be consolidated without losing capability.

Completeness4/5

The tool surface covers the main lifecycle well: discovery, point-in-time querying, filings search and full text, backtesting, research, risk assessment, alerts, memory, approvals, and provenance verification. Minor gaps exist—no strategy management tools, no memory deletion, no bulk export—but agents can work around them.

Resources