ETFIQ

compare_to_benchmark

Read-onlyIdempotent

Sets an allocation ETF, or a portfolio build_portfolio builds, beside an ETFIQ benchmark. With ticker (such as AOR): how the fund did against the benchmark for its band (set by its look-through stock share), over the same dates, as ETFIQ published it: total returns by window and the difference, risk and cost. With portfolio (the arguments build_portfolio took, its answer's compare.arguments.portfolio): the same portfolio built again beside an ETFIQ benchmark, the benchmark's own 1Y, 3Y, 5Y, 10Y and since-inception windows exactly as published, each with its dates and basis (hypothetical before the freeze date), and the differences in stock share and weighted fee in percentage points; and, in portfolio_returns, the portfolio's hypothetical returns beside the benchmark's over the same months, window by window, with each difference in percentage points. WHICH BENCHMARK: without benchmark, the default rule's (the ETFIQ strategic benchmark nearest the portfolio's looked-through stock share, the lower on a tie; for the band form, its band's), and choice.line says why in one line. When that one is more than 5 percentage points from the stock share, or the share is as near another strategic benchmark, the next-nearest is set beside it in also, with the same windows and differences, and choice.gap.line says so. When the reader names another ETFIQ benchmark ("compare it to Strategic 80 instead"), pass benchmark with their words or its id (etfiq-strategic-80): any benchmark list_benchmarks returns. That one is used, and choice.line still names the default and why. A name that matches no benchmark is refused (kind unknown-benchmark) with the list. Refuses, and estimates nothing, when ETFIQ has not published what is asked.

Input Schema

Name	Required	Description
`ticker`	No	An allocation ETF, such as AOR.
`benchmark`	No	Optional, with portfolio: an ETFIQ benchmark the reader names, by id (etfiq-strategic-80) or name (Strategic 80). Leave it out for the default rule.
`portfolio`	No	The arguments build_portfolio took: its answer's compare.arguments.portfolio.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

addedInput schema / properties / benchmark

Added value: +{
+  "description": "Optional, with portfolio: an ETFIQ benchmark the reader names, by id (etfiq-strategic-80) or name (Strategic 80). Leave it out for the default rule.",
+  "type": "string"
+}

Changed3 schema fields changedOct 17, 2026

addedInput schema / properties / portfolio

Added value: +{
+  "description": "The arguments build_portfolio took: its answer's compare.arguments.portfolio.",
+  "type": "object"
+}

addedInput schema / properties / ticker / description
```
Added value: +"An allocation ETF, such as AOR."
```
removedInput schema / required
```
Removed value: -[
-  "ticker"
-]
```

AddedOct 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds genuine beyond-schema behavior: the default selection rule including tie-breaking, the >5pp next-nearest rule, refusal with kind unknown-benchmark plus list, and that it estimates nothing when unpublished. It does not cover output shape, but there is no output schema so some return-format detail is absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one enormous run-on block with nested colons and semicolons, front-loading is weak, and key facts like the 5pp rule are buried mid-passage. Every fact arguably earns its place, but the structure is hard to parse and would benefit from being broken into labeled segments.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, nested object param, and dual input modes, the description is thorough: it covers default selection, override, refusal, and the window/difference structure returned in both modes. Minor gap: it does not describe the output shape for the ticker mode's risk/cost fields in detail.

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, but the description adds real semantic value: it explains the default rule for omitting benchmark, clarifies benchmark's id-vs-name forms, and elaborates what the portfolio object is (build_portfolio's compare.arguments.portfolio). It goes beyond the schema's succinct parameter descriptions.

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?

The description names a specific verb (compare/set beside) and both resource forms (allocation ETF or a built portfolio) against an ETFIQ benchmark, and it distinguishes ticker mode from portfolio mode. It is clear what the tool does, though the dense phrasing makes the core purpose have to be excavated from long sentences.

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?

Explicitly states when the benchmark defaults, when a comparison 'also' is set (gap >5pp or tie), and when to pass a reader-named benchmark with the exact phrasing and id format. It also documents the failure paths (unknown-benchmark refused, no estimate when unpublished), which is exceptional routing guidance.

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

All ETFIQ 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?