Bullrun

Compare ETFs

compare_etfs

Read-only

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

Name	Required	Description
`include`	No	Selected comparison modules. overlap is opt-in and returns pairwise shared holdings and weighted overlap from each fund's latest stored snapshot.
`tickers`	Yes	Two to ten exact Bullrun ETF listing tickers.
`topSharedLimit`	No	Maximum shared holdings per ETF pair when overlap is requested; does not limit the snapshots used in overlap calculations.
`performanceDays`	No	Window 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

Name	Required	Description	Default
`rows`	Yes
`leaders`	Yes
`overlap`	No
`tickers`	Yes
`webPage`	No
`coverage`	Yes
`warnings`	Yes
`platformLink`	No
`requestedModules`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 20, 2026

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"
+]

Changed2 schema fields changedOct 19, 2026

changedInput schema / properties / performanceDays / default
```
Previous value: -370New value: +365
```

addedInput schema / properties / performanceDays / description

Added value: +"Window 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."

Changed2 schema fields changedOct 12, 2026

addedOutput schema / properties / platformLink

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "description": {
+      "type": "string"
+    },
+    "label": {
+      "type": "string"
+    },
+    "url": {
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "required": [
+    "label",
+    "url",
+    "description"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / webPage

Added value: +{
+  "format": "uri",
+  "type": "string"
+}

AddedAug 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses real behavioral traits: overlap matching by security identity rather than ticker, exclusion of cash/currency/derivatives, missing holdings making overlap unavailable, partial holdings making it a lower bound, and that leaders are mechanical extrema rather than recommendations. These are exactly the caveats an agent needs to interpret results honestly.

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 core purpose is front-loaded in the first sentence and the remaining clauses each carry caveat information. Minor waste: the trailing 'Read-only.' restates the readOnlyHint annotation, and the middle is a dense run of caveat clauses that could be itemized.

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 multi-module comparison tool with an output schema (so return structure needn't be explained), the description covers selection semantics, failure modes, interpretation guidance, and currency/date caveats. Nothing material is missing for correct invocation.

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 the baseline is 3, but the description adds semantics the schema lacks — identity-based matching, derivative/cash exclusion, and lower-bound behavior for the overlap module and its stored-snapshot basis. It does not expand on performanceDays or topSharedLimit beyond the already-rich schema text.

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 and resource ('normalized side-by-side comparison of two to ten ETFs') and enumerates exactly which modules the comparison spans. An agent can distinguish it from single-fund siblings like get_etf_holdings or get_etf_snapshot and from compare_stocks without opening the schema.

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

Usage Guidelines3/5

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

Usage is implied by the comparison framing and the note that 'only requested modules run' and 'overlap alone fetches no price history', which helps with module budgeting. However, it never routes the agent against alternatives — it does not say when to prefer this over get_etf_holdings, screen_etfs, or compare_company_exposures, nor any exclusions or prerequisites.

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

All Bullrun 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.