Skip to main content
Glama

Weight a stock screen or list

solve_equity_weights
Read-onlyIdempotent

Weight a single-stock portfolio on one date, without saving anything.

The ad hoc form of ``build_equity_strategy``: the same universe and construction
arguments with the same defaults, solved once instead of saved, so the weights
are the ones that build would hold today. Screen live (the ``request``
``screen_equities`` echoed) or pin ``asset_ids``, a list the client brings. The
caps bind every method, 10% per stock unless given, as in the build; N names need
a cap of at least 1/N. A relaxed cap is reported in ``notes``, as is what a
liquidity limit (``assumed_aum_usd``) zeroed or relaxed.

Names asked for that hold no weight are listed in ``unweighted``. ``request``
plus a name is the ``build_equity_strategy`` call that saves it, re-screened at
every rebalance; the weighted ids are today's picks, and saved as ``asset_ids``
they give a backtest hindsight bias. The asset ids
and weights, passed as ``holdings``, are what the ``describe_portfolio_*`` reads
measure unsaved. One date (``date``, default the latest), so no track record.
Funds and ETFs are weighted with ``solve_allocation_weights``. A themed screen
also names any catalogue strategy on the same theme, as an alternative to saving.
Where a card is drawn it lists every holding, so one weighting is one call.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "solve_equity_weights"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNo
sizesNo
themesNo
regionsNoISO-3 country codes ('SWE'), country names ('Sweden') or the groups 'global', 'nordics', 'europe' (which includes the Nordics) and 'north_america'. Where a company is LISTED, not where it is based: a foreign company with a local listing counts in that country.
sectorsNo
asset_idsNo
esg_filterNo
industriesNo
constructionNorisk_parity
fundamentalsNo
gics_excludeNoGICS codes whose companies are dropped, at any level: 2-digit sectors, or 4-, 6- and 8-digit codes from find_gics.
theme_excludeNo
assumed_aum_usdNo
company_excludeNo
max_stock_weightNo
max_sector_weightNo
max_country_weightNo
min_dividend_yieldNoKeep only companies whose trailing 12-month dividend yield is at least this, e.g. 0.03 for 3%. Applied after a tilt: the tilt keeps its share (fundamentals_percentage_select) of the screened universe, then the floor keeps the yielders among those.
max_adv_participationNoLargest share of a stock's one-month average daily volume one position may equal. The volume is the primary listing's alone, not consolidated across venues and dark pools, so the limit is conservative.
maximum_number_of_assetsNoAt most 500; empty means 500.
fundamentals_percentage_selectNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $defs / AssumedAum / description
      Previous value: -"Portfolio size in USD to size a liquidity limit for: no position above max_adv_participation of the stock's one-month average daily volume at this size. Binds risk_parity and min_risk only. Omitted: no liquidity limit."New value: +"Portfolio size in USD to size a liquidity limit for: no position above max_adv_participation of the stock's one-month average daily volume at this size. Omitted: no liquidity limit."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses the binding 10% default cap, the constraint that N names require a cap of at least 1/N, that a relaxed cap and liquidity-driven drops appear in `notes`, that zero-weight names surface in `unweighted`, and that pinning asset_ids introduces backtest hindsight bias. With no output schema, these return-content and constraint disclosures carry real weight.

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 distinguishing fact — unsaved, one-date weighting — is front-loaded and most sentences carry unique information. The middle passage is dense and back-loaded with cross-references ('request plus a name is the build_equity_strategy call that saves it...'), which slows parsing but does not waste space.

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 21-parameter tool with no output schema, the description covers the decisive behaviors: default cap, date handling, reporting keys, and the relationship to the saved build and to portfolio reads. The remaining gap is the unexplained portion of the parameter surface, which the partial schema descriptions only partly cover.

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?

Schema coverage is only 24% across 21 parameters, and the description adds meaning to just a few (date default, max_stock_weight default and 1/N rule, assumed_aum_usd liquidity limit, asset_ids). It also refers to a `request` argument for the screen_equities form that does not exist as a named property in the schema, which could mislead an agent into looking for it. Construction, fundamentals, sector/country caps and the exclusion filters get no explanation in the description.

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 opening sentence states a specific verb and resource ('Weight a single-stock portfolio on one date, without saving anything') and the second names the sibling it mirrors ('The ad hoc form of build_equity_strategy'). An agent can distinguish it from build_equity_strategy, solve_allocation_weights and describe_portfolio_* without opening any schema.

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

Usage Guidelines5/5

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

Explicit routing is given for each alternative: use this for an unsaved one-off, build_equity_strategy to save it, solve_allocation_weights for funds and ETFs, describe_portfolio_* to measure holdings, and screen_equities to produce the live screen. The 're-screened at every rebalance' versus 'today's picks' contrast clarifies the when-to-use boundary rather than leaving it implied.

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