Bullrun

Compare funds tracking one index

get_etf_index_group

Read-only

Find and rank every fund tracking an index by fee, collapsing duplicate venue listings, so you can compare UCITS tracking costs; omit indexKey to list available index families.

Instructions

Answer "what is the cheapest way to track ?". Returns every fund tracking one index ordered cheapest fee first, deduplicated to one row per FUND rather than per venue listing (a five-venue UCITS fund is one choice, not five) with its listingCount and venues. Defaults to UCITS-buyable domiciles. Omit indexKey to list the available index families. Fees are percentage points and the response states how many funds publish no fee at all, so a "cheapest" claim is never made over silently omitted funds. Read-only.

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum funds (or index families) to return, 1-100.
`scope`	No	ucits (default) restricts to domiciles a European retail investor can actually buy. all adds US-domiciled trackers, which look cheaper but are not purchasable by EU retail.	ucits
`currency`	No	Keep only funds with a listing trading in this currency (e.g. CHF, EUR, USD, GBP) and name that line.
`exchange`	No	Keep only funds listed on this venue and name each one's ticker there, e.g. SW (SIX Swiss Exchange), XETRA, LSE, AS, MI. A Swiss investor wanting the SIX line passes SW.
`indexKey`	No	Normalized index key, e.g. SP500, MSCI_WORLD, NASDAQ100, MSCI_EM, EURO_STOXX_50, TOPIX, FTSE100. Omit to list every index family that has at least one fund.
`distributionPolicy`	No	Optionally keep only accumulating or only distributing share classes.

Output Schema

Name	Required	Description	Default
`mode`	Yes
`found`	Yes
`funds`	Yes
`scope`	Yes
`webPage`	No
`coverage`	Yes
`indexKey`	Yes
`warnings`	Yes
`platformLink`	No
`indexFamilies`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.0Oct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses ordering, the fund-vs-venue dedup behavior, listingCount/venues in the result, the domicile default, and that the response reports how many funds publish no fee so 'cheapest' claims aren't made over silent omissions. That is exactly the kind of context annotations cannot carry.

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 user question and mostly waste-free, but the single dense run-on sentence packs several ideas (dedup, defaults, fee disclosure) and could be broken for scanability.

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?

For a read-only screening tool with 6 optional params, an output schema, and full annotation coverage, the description supplies ordering, dedup semantics, default scope, and data-quality caveats. Nothing an agent needs to call it correctly 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 coverage is 100%, so baseline is 3; the description earns extra by explaining indexKey omission as a mode switch and by surfacing listingCount/venues as output concepts tied to the filtering parameters. Currency/exchange semantics are left largely to the schema.

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?

Opens with the exact question it answers and states a specific resource (every fund tracking one index, ordered cheapest fee first). The dedup rule ('one row per FUND rather than per venue listing') sharply distinguishes it from raw listing/search tools like search_etfs.

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 concrete routing guidance: omit indexKey to enumerate index families, and scope defaults to UCITS-buyable domiciles with 'all' adding US trackers. It does not explicitly name alternatives such as compare_etfs or simulate_etf_cost, so the when-not case must be inferred.

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

Deploy Server