Folionomiq

What the funds hold underneath

look_through

Read-onlyIdempotent

The companies a portfolio owns through its funds, added up across funds. In: holdings. Out: the largest companies with their share of the whole portfolio, companies reached through more than one fund, the part of the money that buys a company a second time, sectors, and how much of the money could be named. Typical questions: 'How much do my ETFs overlap?'; 'What companies do I really own through VTI, QQQ and VXUS?'; 'How much NVIDIA do I hold through my funds?'. Instead: for one fund on its own, asset_info. Figures are minimums where a fund shows only its largest holdings; the answer says how much of the money is named. It does not recommend, predict or calculate tax.

Input Schema

Name	Required	Description
`base`	No	Currency code every figure is expressed in: USD, EUR, GBP, CAD… Default USD.
`units`	No	What the holdings' numbers are: 'money' (amounts in the base currency) or 'weights' (percentages or fractions). Omitted: holdings adding up to 1 or 100 are read as percentages, anything else as money, and the answer says so.
`holdings`	Yes	What is held: {ticker: number}, 1 to 100 holdings. Weights in any scale (60/20/20 or 0.6/0.2/0.2) or money amounts in the base currency (60000/20000/20000): `units` says which; without it, holdings adding up to 1 or 100 are read as percentages, anything else as money, which makes the falls come out in money. Tickers as the exchange lists them (VOO, VWCE.DE, EQQQ.DE, XAW.TO; 'CASH.USD' for cash). Example: {"VTI": 60, "VXUS": 20, "BND": 20}.

Output Schema

Name	Required	Description
`data`	No	Where the prices came from and what was missing or repaired.
`_fence`	Yes	What these figures are and are not: descriptive, no forecast, no advice. Repeat its sense when presenting the result.
`opaque`	No	Holdings with no breakdown to look through.
`n_funds`	No	Funds looked through.
`refused`	No	Funds whose breakdown the data vendor refused.
`sectors`	No	[sector, share] pairs.
`exposures`	No	[company, share of the whole portfolio] pairs, largest first.
`top_symbol`	No	The largest single company underneath.
`n_companies`	No	Distinct companies seen underneath.
`covered_fraction`	No	Share of the money whose underlying holdings are visible, 0 to 1.
`top_symbol_weight`	No	Its share of the whole portfolio.
`duplicated_exposure`	No	Share held more than once through different funds.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

changedInput schema / properties / holdings / description

Previous value: -"What is held: {ticker: number}, 1 to 100 holdings. Weights in any scale (60/20/20 or 0.6/0.2/0.2) or money amounts in the base currency (60000/20000/20000): holdings adding up to 1 or 100 are read as percentages, anything else as money, which makes the falls come out in money. Tickers as the exchange lists them (VOO, VWCE.DE, EQQQ.DE, XAW.TO; 'CASH.USD' for cash). Example: {\"VTI\": 60, \"VXUS\": 20, \"BND\": 20}."New value: +"What is held: {ticker: number}, 1 to 100 holdings. Weights in any scale (60/20/20 or 0.6/0.2/0.2) or money amounts in the base currency (60000/20000/20000): `units` says which; without it, holdings adding up to 1 or 100 are read as percentages, anything else as money, which makes the falls come out in money. Tickers as the exchange lists them (VOO, VWCE.DE, EQQQ.DE, XAW.TO; 'CASH.USD' for cash). Example: {\"VTI\": 60, \"VXUS\": 20, \"BND\": 20}."

addedInput schema / properties / units

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "money",
+        "weights"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "What the holdings' numbers are: 'money' (amounts in the base currency) or 'weights' (percentages or fractions). Omitted: holdings adding up to 1 or 100 are read as percentages, anything else as money, and the answer says so.",
+  "title": "Units"
+}

Changed2 schema fields changedOct 22, 2026

changedInput schema / properties / base / description

Previous value: -"Currency every figure is expressed in (USD, EUR, GBP, CAD…). Default USD."New value: +"Currency code every figure is expressed in: USD, EUR, GBP, CAD… Default USD."

changedInput schema / properties / holdings / description

Previous value: -"What is held: {ticker: weight or amount}. Weights need not sum to one; amounts in the base currency are also accepted (then the crises are shown in money). 1 to 100 holdings. Tickers as the exchange lists them (VOO, VWCE.DE, XAW.TO; 'CASH.USD' for cash)."New value: +"What is held: {ticker: number}, 1 to 100 holdings. Weights in any scale (60/20/20 or 0.6/0.2/0.2) or money amounts in the base currency (60000/20000/20000): holdings adding up to 1 or 100 are read as percentages, anything else as money, which makes the falls come out in money. Tickers as the exchange lists them (VOO, VWCE.DE, EQQQ.DE, XAW.TO; 'CASH.USD' for cash). Example: {\"VTI\": 60, \"VXUS\": 20, \"BND\": 20}."

AddedSep 25, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds important caveats: figures are minimums when funds disclose only top holdings, the answer reports named coverage, and the tool does not recommend, predict, or calculate tax. It does not discuss rate limits or authentication, but those are not central for this local analysis tool.

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?

Front-loads the purpose and expected output, then gives examples and exclusions. It is somewhat long, but most sentences earn their place by clarifying output scope or avoiding misuse.

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?

Given an output schema exists, the description need not restate return fields in detail, and it already names the main output categories plus key limitations. For a read-only analytical tool with fully described parameters, this is complete enough to invoke correctly.

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

Parameters4/5

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

Schema coverage is 100%, so parameter definitions already carry the baseline. The description adds useful semantics beyond the schema: ticker formatting conventions, cash notation, 1–100 holdings, and the units inference rule when omitted.

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-like operation and resource: aggregating the companies a portfolio owns through its funds. It also distinguishes the scope from sibling asset_info, so an agent can tell this is portfolio-wide look-through rather than single-fund detail.

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?

Gives explicit typical questions and names the alternative: use asset_info for one fund on its own. That directly routes the agent between this tool and a close sibling.

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

All Folionomiq tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?