jawz

Get ETF profile

get_etf_profile

Read-only

ETF look-through for Chapter 2 Mode 2.2 (Concentration Check). Given ETF ticker(s), returns each fund's top holdings with weights so the AI can overlay them with the user's direct positions and surface hidden single-name concentration. Each profile carries source='live' (Vanguard API, fresh) or source='catalog' (dated snapshot — see as_of). Holdings are TOP-N only, so any true-exposure figure computed from this is a floor, not exact. Bond and commodity ETFs return no holdings by design. Tickers not in the catalog come back in unknown_tickers; their contents are not known to Jawz and no holdings are returned for them.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tickers`	Yes	ETF ticker symbols to look through (e.g. ['QQQ','VGT','SPY'])

Output Schema

TableJSON Schema

Name	Required	Description	Default
`coverage`	No
`guidance`	No
`profiles`	No
`requested`	No
`data_sources`	No
`terms_glossary`	No
`unknown_tickers`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 6, 2026

changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +true
```

addedOutput schema / properties / terms_glossary

Added value: +{
+  "anyOf": [
+    {
+      "anyOf": [
+        {
+          "not": {}
+        },
+        {
+          "additionalProperties": true,
+          "properties": {},
+          "type": "object"
+        }
+      ]
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations mark this as read-only and non-destructive, and the description adds substantial behavioral context beyond that: data can be 'live' or a dated 'catalog' snapshot, holdings are TOP-N so exposure is a floor, bond/commodity ETFs return no holdings by design, and unknown tickers are surfaced in unknown_tickers. This is rich, accurate, and non-contradictory.

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

Conciseness5/5

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

Four sentences, each carrying distinct value: the use case, the source/data freshness distinction, the TOP-N limitation, and edge-case behavior. The most important information is front-loaded and the description is efficient without being terse.

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 read-only tool with a single parameter and an output schema, the description covers the essential operational details: purpose, data provenance, freshness semantics, coverage limitations, and unknown-ticker behavior. Nothing critical is missing for an agent to invoke and interpret the tool correctly.

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?

The schema already documents the sole parameter (tickers) with examples, so the baseline is 3. The description adds meaningful semantic value by explaining how unknown tickers are handled, that only top-N holdings are returned, and that certain ETF types yield no holdings—all directly relevant to using the parameter correctly.

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 clearly identifies the tool's function: ETF look-through that returns top holdings and weights for concentration checks. It distinguishes itself from the broad set of sibling 'get_' tools by specifically targeting Chapter 2 Mode 2.2 and by explaining why it exists.

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?

The description gives explicit usage context: this is for the Concentration Check in Chapter 2 Mode 2.2, and explains how the AI should use it to overlay holdings with direct positions. It does not explicitly name alternatives or when-not-to-use, but the context is strong and no sibling tool competes directly.

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

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