FinChiefs

Summarize views

summarize_views

Read-only

The overall picture from EVERY matching view in one small response: totals, up/down counts (asset views), how many providers lean each way, the busiest providers, a week-by-week trend, and the most-discussed assets or macro categories. Start here for "what is the consensus / how has it changed" questions, then read individual views with search_asset_views or search_macro_views.

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": {
      "kind": "<kind>"
    },
    "name": "summarize_views"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	Asset (directional) views or macro theme views.
`since`	No	Start date YYYY-MM-DD. Default: 30 days ago. The free plan reaches back 30 days for summaries.
`terms`	No	Subject words to match (assets, tickers, countries, central banks, companies, themes). Whole-word, case-insensitive; any term may match. Include synonyms and tickers, e.g. ["gold", "xau", "bullion"]. Omit to get everything in range. Asset views: matched against the asset name. Macro views: against the theme name and description.
`until`	No	End date YYYY-MM-DD, inclusive. Default: today.
`category`	No	Macro views only: a macro category key from list_categories, e.g. "monetary_policy".
`asset_class`	No	Asset views only.
`provider_id`	No	Limit to one research provider (id from list_providers).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by describing the response shape (small aggregate rather than raw records), which matters because there is no output schema. It stops short of noting plan/date-range limits or rate behavior, keeping it from a 5.

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?

Two sentences, front-loaded with the aggregate result and then the routing advice. Every clause carries information: the response contents and the drill-down alternative.

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 aggregation tool with no output schema, the description compensates by enumerating the aggregates returned and the scope ('EVERY matching view'), so the agent knows what it gets without a return schema. Combined with the rich input schema, nothing needed to call it correctly 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%, so kind, terms, dates, category, asset_class and provider_id are already fully explained in the schema. The description adds no additional parameter meaning; 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?

Specific verb (summarize) plus resource (views) and an explicit enumeration of what the summary contains: totals, up/down counts, provider leans, trends, top subjects. It also distinguishes itself from search_asset_views and search_macro_views, which return individual views rather than the aggregate.

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 tells the agent to start here for consensus/change questions, then drill into individual views via the two named sibling search tools. Both the entry point and the follow-up path are stated, leaving nothing to infer.

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

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