Skip to main content
Glama

Kaleidoscope MCP (SEC & financial data)

Graph Aggregate (rank entities by an aggregate over their edges — the screen primitive) [beta]

graph_aggregate
Read-onlyIdempotent

The graph SCREEN primitive — rank entities BY an aggregate over their edges (the cross-node complement to graph_neighbors' single-node walk). 'Which companies have the most 13D filers', 'most widely-held stocks', 'busiest placement agents', 'most-interlocked directors'.

Pick an edge_type (discover via graph_schema), a group_side ('src' or 'dst' — which END of the edge to rank), and a metric: • n_edges — count of edges (e.g. # 13D filings on a company) • n_counterparties — count of DISTINCT other-side entities (e.g. # distinct 13D filers — usually what you want for 'most-targeted') • sum:<signal> — sum of a numeric edge signal (e.g. sum:value_usd on holds/dst = biggest aggregate institutional $ position; signals per edge come from graph_schema).

Examples: holds / dst / n_counterparties → most widely-held stocks; holds / dst / sum:value_usd → biggest $ held; filed_13d_on / dst / n_counterparties → most-targeted companies; placed_offering_for / src / n_edges → busiest placement agents; board_member_of / src / n_edges → most-interlocked directors.

Each row: resolved name + node_id + n_edges + n_counterparties + signal_sums + as_of_max (freshness of the underlying edges). Data is a nightly rollup (refreshed_at echoed) — current to ~last night, which is right for these rankings. Catalog-driven: every graph edge is screenable, new edges auto-join. min_value floors the metric; node_type filters the grouped node type.

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": {
      "edge_type": "<edge_type>",
      "group_side": "<group_side>"
    },
    "name": "graph_aggregate"
  }
}

Input Schema

NameRequiredDescriptionDefault
top_nNoHow many to return (default 25, max 200).
metricNon_edges | n_counterparties | sum:<signal> (e.g. 'sum:value_usd'). Default n_edges.n_edges
edge_typeYesWhich edge to aggregate (from graph_schema).
min_valueNoOnly rows whose metric ≥ this.
node_typeNoOptional filter on the grouped node's type (company/person/investor/institution/foundation).
group_sideYesWhich end of the edge to rank: 'src' (e.g. the filer/holder/agent) or 'dst' (e.g. the company held/targeted).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral context: the data is a nightly rollup ('current to ~last night'), freshness surfaces as `as_of_max` with `refreshed_at` echoed, and the catalog is self-expanding ('every graph edge is screenable, new edges auto-join'). It also discloses the row shape returned, which matters since there is no output schema.

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-loaded with the core purpose and the three key knobs before examples, and every section maps to a parameter. The bullet list plus a second example block covering overlapping cases makes it longer than strictly necessary, but no sentence is filler.

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 six-parameter analytical tool with no output schema, the description supplies what the schema cannot: the returned columns, freshness semantics, discovery path for `edge_type`, and the metric vocabulary. An agent could construct a correct call and interpret the result from this text alone.

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 the baseline is 3, but the description adds real meaning: it explains that `group_side` selects which END of the edge is ranked (with filer-vs-company framing), distinguishes `n_edges` from `n_counterparties` (distinct other-side entities), explains the `sum:<signal>` form with a concrete example, and clarifies `min_value` and `node_type` roles.

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 states a specific verb and resource ('rank entities BY an aggregate over their edges') and explicitly positions the tool against a named sibling ('the cross-node complement to graph_neighbors' single-node walk'). Concrete example questions ('which companies have the most 13D filers') make the purpose unmistakable.

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?

It says to discover `edge_type` via graph_schema, explains how to pick `group_side` and which `metric` suits which question ('n_counterparties — usually what you want for most-targeted'), and gives five worked edge_type/side/metric combinations. It lacks an explicit when-not statement, but the graph_neighbors contrast and metric-choice guidance cover most selection decisions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources