TickerInside ETF Holdings

ETFs that diversify a portfolio

find_diversifying_etfs

Read-onlyIdempotent

Use this when the user asks which ETFs would diversify an ETF or a portfolio of ETFs, what could be added to diversify it, or which ETFs moved least with what they hold. Ranks a fixed, published list of 30 large US ETFs across six kinds of exposure (US, sector, international and emerging market stocks, bonds and commodities) by the correlation of their weekly returns with the portfolio's over up to three years, and returns the ETF of lowest correlation in each of the three groups whose lowest is lowest, with its correlation on the weeks the portfolio fell, the portfolio's volatility with 10% in it and its overlap by weight, then the next ETFs of the list. Takes 1 to 6 ETFs held. A measurement of past co-movement, not investment advice; every answer carries that note. Not for the overlap of ETFs the user names (compare_etfs, get_etf_overlap_matrix) or the risk of the portfolio itself (get_etf_portfolio_risk).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "positions": "<positions>"
    },
    "name": "find_diversifying_etfs"
  }
}

Input Schema

Name	Required	Description	Default
`positions`	Yes	The ETFs held, 1 to 6, for example [{"ticker": "VOO", "amount": 60000}, {"ticker": "QQQ", "amount": 20000}]. Give an amount for every position or for none; with none, every ETF counts equally.

Output Schema

Name	Required	Description	Default
`note`	No
`answer`	No
`lowest`	No
`covered`	No
`left_out`	No
`page_url`	No
`question`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

addedOutput schema / properties / left_out

Added value: +{
+  "items": {
+    "properties": {
+      "ticker": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "ticker"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

AddedOct 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description still adds substantial behavior: the ETF universe is a fixed published list of 30, the metric is weekly-return correlation over up to three years, the selection rule is the lowest correlation in each of three groups, and results include downside correlation, volatility with 10% allocated, and weight overlap. It also discloses the disclaimer note attached to every answer, which no annotation covers.

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 trigger condition is front-loaded and every sentence carries information the agent needs. However, the central sentence describing the ranking and returned fields is a long run-on that requires re-reading, which mildly blunts comprehension of the most important behavioral detail.

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 single-parameter, analytical tool with an output schema already present, the description covers universe, methodology, selection rule, and the nature of the returned fields, plus an explicit boundary against siblings. Nothing an agent needs in order to call this correctly or interpret the result is missing.

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% and the nested ticker/amount fields are already documented in the schema, including the equal-weighting rule, so the schema does the heavy lifting. The description only adds the constraint of 1 to 6 held ETFs, which is already implied by minItems/maxItems. Baseline 3 is appropriate.

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?

The description names a specific verb and resource ('ranks a fixed, published list of 30 large US ETFs ... by the correlation of their weekly returns with the portfolio's') and explicitly distinguishes itself from the three siblings that cover adjacent questions (compare_etfs, get_etf_overlap_matrix, get_etf_portfolio_risk). An agent can tell exactly what class of answer this tool produces.

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?

It opens with the trigger phrasing ('Use this when the user asks which ETFs would diversify...') and closes with explicit when-not guidance naming the alternative tools for overlap-of-named-ETFs and portfolio risk. Both the positive and negative routing conditions are stated, leaving nothing to inference.

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

All TickerInside ETF Holdings 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?