Bullrun

Get ETF exposures

get_etf_exposures

Read-only

Calculate an ETF's sector, country, currency, and broad asset exposures from stored holdings, with coverage stated so partial data is not mistaken for full exposure.

Instructions

Calculate sector, country, currency, and broad asset exposure from the latest stored ETF holdings. Sector and country come from the fund provider's own holdings file where it states them (normalized to Bullrun's sector and country names), otherwise from the Bullrun instrument the holding resolves to by ISIN or by symbol with a matching company name. Currency uses the reported holding currency, else an explicitly disclosed estimate from the company's home-market listing or usual country currency. This is a holding quote/listing-currency proxy, not revenue FX exposure, economic currency risk or hedge-adjusted fund exposure. Positions without a classification or currency basis are Unclassified / Not reported. Sector and currency cover all stored rows; country covers securities and excludes cash and derivatives. Coverage states complete bucket weights and any buckets omitted by limitPerType. Broad asset class comes from the normalized fund profile. Factor and thematic look-through are unavailable until dedicated source data exists. Coverage states how much fund weight was classified and how, so partial top-holdings data is never presented as full exposure. Read-only.

Input Schema

Name	Required	Description
`types`	No
`ticker`	Yes	Exact Bullrun ETF listing ticker.
`limitPerType`	No

Output Schema

Name	Required	Description	Default
`ticker`	Yes
`webPage`	No
`coverage`	Yes
`warnings`	Yes
`exposures`	Yes
`platformLink`	No
`availableTypes`	Yes
`notLoadedTypes`	No
`requestedTypes`	Yes
`unavailableTypes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.1Oct 22, 2026

addedOutput schema / properties / notLoadedTypes

Added value: +{
+  "items": {
+    "$ref": "#/properties/requestedTypes/items"
+  },
+  "type": "array"
+}

Addedv0.7.0Oct 19, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already cover the read-only safety profile, and the description adds substantial behavior beyond them: resolution fallbacks (provider file, then ISIN, then symbol with matching company name), what is excluded per dimension (country excludes cash and derivatives while sector and currency cover all rows), how unclassified positions are labeled, and how coverage/limitPerType truncation is reported. It also discloses a genuine limitation (no factor/thematic look-through) rather than leaving the agent to discover it.

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-loaded with the core action and dimensions in the first sentence, then methodology and caveats in descending importance. Some redundancy: two separate sentences are spent on coverage reporting, and the trailing 'Read-only.' duplicates readOnlyHint=true.

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?

An output schema exists, so return-value structure need not be explained; the description instead covers what the agent cannot get from schema or annotations — data provenance, fallback chain, per-dimension exclusions, and partial-coverage honesty. Nothing material for correct invocation is missing.

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 description coverage is only 33% (only ticker is documented), so the description must compensate and largely does: it enumerates the four exposure dimensions the types enum can request and flags that factor/thematic will not return data. It also explains that limitPerType causes bucket omission and that coverage reports those omissions. It does not document the types default list or per-enum behavior beyond the four named buckets, so it is not fully compensating.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Calculate sector, country, currency, and broad asset exposure from the latest stored ETF holdings.' An agent can tell this is a derived-exposure tool rather than a raw holdings dump. It does not explicitly name the sibling it differs from (e.g. get_etf_holdings or compare_etf_exposures), so it stops short of full sibling differentiation.

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?

Gives clear usage context: exposure is computed only from stored holdings, and 'Factor and thematic look-through are unavailable until dedicated source data exists' — which matters because factor and thematic are valid values in the types enum. It also warns the currency output 'is a holding quote/listing-currency proxy, not revenue FX exposure, economic currency risk or hedge-adjusted fund exposure,' steering the agent away from misuse. It never explicitly names an alternative sibling tool to use instead.

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

Deploy Server