Skip to main content
Glama

Compare ETFs

compare_etfs
Read-only

Compare two to ten ETFs side by side across classification, costs, performance, risk, holdings and optional overlap to evaluate shared securities and weighted exposure.

Instructions

Return a normalized side-by-side comparison of two to ten ETFs across selected classification, market, fund-data, cost, income, benchmark, price-performance, price-risk, holdings, and optional overlap modules. Include overlap to measure pairwise shared securities and weighted overlap from latest stored holdings, matched by security identity rather than ticker alone; cash, currency and derivatives are excluded. Missing holdings make overlap unavailable, while partial holdings make it a lower bound. Only requested modules run; overlap alone fetches no price history. Leaders are mechanical extrema, not recommendations. Currency, holdings dates and coverage caveats are explicit. Read-only.

Input Schema

NameRequiredDescriptionDefault
includeNoSelected comparison modules. overlap is opt-in and returns pairwise shared holdings and weighted overlap from each fund's latest stored snapshot.
tickersYesTwo to ten exact Bullrun ETF listing tickers.
topSharedLimitNoMaximum shared holdings per ETF pair when overlap is requested; does not limit the snapshots used in overlap calculations.
performanceDaysNoWindow in calendar days back from each fund's newest close; the start is the last close on or before that day. 365 matches the fund page and the screener's 1-year return.

Output Schema

NameRequiredDescriptionDefault
rowsYes
leadersYes
overlapNo
tickersYes
webPageNo
coverageYes
warningsYes
platformLinkNo
requestedModulesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.8.1
    • addedInput schema / properties / include / description
      Added value: +"Selected comparison modules. overlap is opt-in and returns pairwise shared holdings and weighted overlap from each fund's latest stored snapshot."
    • changedInput schema / properties / include / items / enum
      Previous value: -[
      -  "classification",
      -  "market",
      -  "fund_data",
      -  "costs",
      -  "income",
      -  "benchmark",
      -  "performance",
      -  "risk",
      -  "holdings"
      -]New value: +[
      +  "classification",
      +  "market",
      +  "fund_data",
      +  "costs",
      +  "income",
      +  "benchmark",
      +  "performance",
      +  "risk",
      +  "holdings",
      +  "overlap"
      +]
    • changedInput schema / properties / include / maxItems
      Previous value: -9New value: +10
    • addedInput schema / properties / topSharedLimit
      Added value: +{
      +  "default": 20,
      +  "description": "Maximum shared holdings per ETF pair when overlap is requested; does not limit the snapshots used in overlap calculations.",
      +  "maximum": 100,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedOutput schema / properties / overlap
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "coverage": {
      +      "items": {
      +        "additionalProperties": {},
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "methodology": {
      +      "additionalProperties": {},
      +      "type": "object"
      +    },
      +    "pairs": {
      +      "items": {
      +        "additionalProperties": {},
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "warnings": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "methodology",
      +    "coverage",
      +    "pairs",
      +    "warnings"
      +  ],
      +  "type": "object"
      +}
    • changedOutput schema / properties / requestedModules / items / enum
      Previous value: -[
      -  "classification",
      -  "market",
      -  "fund_data",
      -  "costs",
      -  "income",
      -  "benchmark",
      -  "performance",
      -  "risk",
      -  "holdings"
      -]New value: +[
      +  "classification",
      +  "market",
      +  "fund_data",
      +  "costs",
      +  "income",
      +  "benchmark",
      +  "performance",
      +  "risk",
      +  "holdings",
      +  "overlap"
      +]
  2. Addedv0.7.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/closed annotations, it discloses real behavior: overlap requires stored holdings, missing holdings make overlap unavailable, partial holdings make it a lower bound, overlap alone triggers no price history, and leaders are mechanical extrema rather than recommendations. Currency, holdings-date and coverage caveats being explicit sets expectations for the output.

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, then layers on module selection and overlap edge cases; every sentence carries information. It is dense and long for a description, with the caveat sentences packable into one, which keeps it just under top marks.

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?

Output schema covers return shape and annotations cover the safety profile, so the description's remaining burden is scope and edge-case behavior — both handled thoroughly via module opt-in, overlap availability bounds, and explicit caveats about currency and holdings dates.

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 description coverage is 100%, so the schema already carries tickers, include enum, topSharedLimit and performanceDays semantics. The description reinforces the opt-in nature of the overlap module but adds no format or constraint detail beyond the schema, so baseline 3 applies.

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 (side-by-side comparison), resource (ETFs), cardinality (two to ten), and scope (named modules). The resource naming also disambiguates it from compare_stocks without needing to reference the sibling explicitly.

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?

"Only requested modules run" and "overlap is opt-in" give clear guidance on how and when to use the costly modules, and the caveat about overlap alone fetching no price history tells an agent what not to expect. It never explicitly routes to alternatives (e.g., get_etf_snapshot for a single fund), so it stops short of a 5.

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