Skip to main content
Glama
Sign In

Ava Advisor

by fund.ava
OverviewDiscussionsAdmin

ETF Profile

etf_profile
Read-only

What a US ETF / fund HOLDS: top holdings with % of NAV, sector (GICS) and country weights, plus the fund facts — AUM, expense ratio, benchmark / index or active, holdings count, top-10 concentration, tracking difference (SEC N-PORT / N-CEN filings; as_of dates say how fresh). Use it for "what does SCHD hold", "how concentrated is QQQ", "SPY vs VOO fees", "sector mix of XLE". ETFs rarely have news of their own — for "why is it moving" pair this with stock_impact / pulse on the top holdings. Non-fund tickers → not_a_fund.

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": {
      "ticker": "<ticker>"
    },
    "name": "etf_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNoHow many top holdings to list (default 15, max 50).
tickerYesA Ava Advisor ticker OR a company/asset NAME — the SERVER resolves it (no lookup step). A COMPANY/proper NAME passes AS-IS in any language (茅台/トヨタ/삼성 resolve natively — never translate a name); a generic COMMODITY/SECTOR concept must be ENGLISH (黄金→'gold', 原油→'crude oil'). Pass the user's full request in `context` to disambiguate ('apple' company vs fruit); if still ambiguous you get a `needs_confirmation` with candidates — resolve from conversation or ask, then re-call. Exact tickers pass through (Ava Advisor suffixes: Korea .KO, Taiwan .TW, commodity .COMM, crypto .CC, FX .FOREX, bond .GB, rate .MM).
contextNoOPTIONAL but RECOMMENDED — paste the user's FULL request VERBATIM (any language: 'ขอราคาผลไม้ apple', 'compare Apple and Microsoft stock'). The server uses it to disambiguate which candidate each `ticker` entity means (the apple COMPANY vs the fruit COMMODITY; which Samsung). One context per call, shared by all tickers here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries most of the burden and does add real context: data provenance (SEC N-PORT / N-CEN filings), freshness semantics via `as_of` dates, and the `not_a_fund` outcome for non-fund tickers. It stops short of describing pagination, size/response-shape limits, or whether data is cached, so it is strong but not exhaustive.

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-loads the core definition ("What a US ETF / fund HOLDS") before enumerating fields, then usage examples, then the sibling-pairing note and the error case. It is dense but every clause serves a purpose; the parenthetical example list is slightly long but justifies itself as routing guidance.

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 read-only lookup tool with a fully documented 3-parameter schema and no output schema, the description covers scope, data sources, freshness, and the main error path. It could say more about the shape of the returned payload (e.g. ordering, nulls when holdings data is missing), but nothing critical to correct invocation 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 schema already explains `ticker` resolution, `context` disambiguation, and `top` (default 15, max 50) in detail. The description adds no parameter-level meaning beyond that, so the 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+resource: what a US ETF/fund holds, with holdings percentages, sector (GICS) and country weights, plus fund facts (AUM, expense ratio, benchmark, holdings count, concentration, tracking difference). It is clearly distinguishable from siblings like financials or price_series, and it explicitly routes news/movement questions to stock_impact / pulse.

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?

Gives concrete example queries ("what does SCHD hold", "SPY vs VOO fees", "sector mix of XLE") that map directly to the tool, names the sibling tools to pair with for a different question type ("why is it moving" → stock_impact / pulse), and states the failure case for non-fund tickers (`not_a_fund`). This is explicit when-to-use and when-to-look-elsewhere guidance.

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

All Ava Advisor toolsInspect
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