Skip to main content
Glama

Weight a multi-asset allocation

solve_allocation_weights
Idempotent

Weight a mix of instruments and strategies on one date, without saving it.

The ad hoc form of ``build_allocation_strategy``: the same arguments and defaults,
solved once instead of saved.

Returns each item's weight and risk contribution, the volatility reached against
the target, and the looked-through instruments. ``request`` plus a name is the
``build_allocation_strategy`` call that saves it; the looked-through ids and
weights, passed as ``holdings``, are what the ``describe_portfolio_*`` reads
measure unsaved. A strategy item the client
owns that holds nothing yet has its holdings published first, as a build does;
``writes`` says so. With ``glide_target_date`` the weights are those of the level in
force today, and ``glide`` is the schedule. ``signal`` scores show on each item.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "solve_allocation_weights"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNo
itemsYes
signalNo
risk_levelNo
loss_toleranceNo
max_asset_weightNo
glide_target_dateNo
max_equity_weightNo
max_sector_weightNo
max_country_weightNo
max_tactical_weightNo
short_rate_asset_idNo
max_alternative_weightNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / $defs / AllocationSignalInput
      Added value: +{
      +  "description": "A client's momentum or factor rule: tilts or filters the unpinned items at each\nrebalance.",
      +  "properties": {
      +    "direction": {
      +      "anyOf": [
      +        {
      +          "$ref": "#/$defs/TiltDirection"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "None: low for valuation, leverage, risk; else high."
      +    },
      +    "keep": {
      +      "anyOf": [
      +        {
      +          "minimum": 1,
      +          "type": "integer"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "Filter only; the items it holds.",
      +      "title": "Keep"
      +    },
      +    "lookback_months": {
      +      "default": 12,
      +      "description": "Momentum sources only.",
      +      "maximum": 36,
      +      "minimum": 1,
      +      "title": "Lookback Months",
      +      "type": "integer"
      +    },
      +    "mode": {
      +      "$ref": "#/$defs/SignalMode",
      +      "default": "tilt",
      +      "description": "'tilt': risk budget x (1 + strength x z), z the capped cross-item score; 0 drops. 'filter': the `keep` best."
      +    },
      +    "skip_months": {
      +      "default": 1,
      +      "description": "Momentum sources only; the latest months left out.",
      +      "maximum": 3,
      +      "minimum": 0,
      +      "title": "Skip Months",
      +      "type": "integer"
      +    },
      +    "source": {
      +      "$ref": "#/$defs/SignalSource",
      +      "description": "'momentum': own return; 'risk_adjusted_momentum': per unit of volatility; the rest: what the item holds."
      +    },
      +    "strength": {
      +      "anyOf": [
      +        {
      +          "maximum": 5,
      +          "minimum": 0.1,
      +          "type": "number"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "Tilt only; 1 when left out.",
      +      "title": "Strength"
      +    }
      +  },
      +  "required": [
      +    "source"
      +  ],
      +  "title": "AllocationSignalInput",
      +  "type": "object"
      +}
    • addedInput schema / $defs / SignalMode
      Added value: +{
      +  "enum": [
      +    "tilt",
      +    "filter"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / $defs / SignalSource
      Added value: +{
      +  "enum": [
      +    "momentum",
      +    "risk_adjusted_momentum",
      +    "valuation",
      +    "profitability",
      +    "leverage",
      +    "risk",
      +    "quality",
      +    "growth",
      +    "dividend_yield"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / $defs / TiltDirection
      Added value: +{
      +  "enum": [
      +    "low",
      +    "high"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / signal
      Added value: +{
      +  "anyOf": [
      +    {
      +      "$ref": "#/$defs/AllocationSignalInput"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only give the binary profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description adds real substance: the response contents (weights, risk contribution, volatility against target, looked-through instruments), the side effect that an empty client-owned strategy item has its holdings published first, and that glide_target_date returns today's level with the full schedule in 'glide'. The 'writes says so' phrasing is terse but consistent with readOnlyHint=false rather than contradicting it.

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

Conciseness3/5

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

The purpose and the sibling relationship are front-loaded, which is good, but the middle is dense and cryptic: 'the looked-through ids and weights, passed as holdings, are what the describe_portfolio_* reads measure unsaved' and '``writes`` says so' take several readings to parse. It is information-rich but not efficiently worded.

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

Completeness3/5

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

For a 13-argument optimizer with no output schema, explaining the return values and the glide/signal behavior is valuable and present. But the constraint and risk-budget inputs that determine whether a solve succeeds are left entirely to an undocumented schema, which is a meaningful gap for a tool of this complexity.

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

Parameters2/5

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

Top-level schema description coverage is 0%, and the description only touches two of the thirteen arguments: glide_target_date (weights of the level in force today) and signal (per-item scores). The many constraint parameters - risk_level, loss_tolerance, max_asset_weight, max_equity_weight, max_sector_weight, max_country_weight, max_tactical_weight, max_alternative_weight, short_rate_asset_id, date - get no explanation of how they interact or which are required to make the optimizer behave, so the description fails to compensate for the coverage gap.

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?

States a specific verb and resource ('weight a mix of instruments and strategies on one date') and immediately pins down its scope ('without saving it'), then names the sibling it mirrors: 'the ad hoc form of build_allocation_strategy ... solved once instead of saved'. An agent can distinguish it from build_allocation_strategy without opening either schema.

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

Usage Guidelines4/5

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

The when-to-use is clear through the contrast with build_allocation_strategy ('request plus a name is the build_allocation_strategy call that saves it'), so an agent knows to pick this one for a non-persisted solve. It does not address the other solver sibling solve_equity_weights or explain when a saved build would be preferred.

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