Kaleidoscope MCP (SEC & financial data)

Graph Resolve (any id → canonical entity node) [beta]

graph_resolve

Read-onlyIdempotent

Mirrored by the cross-family shared resolve tool (same underlying logic, callable regardless of which family you're granted) — kept under this name too since graph-family callers already use it. Resolve any identifier to a canonical graph node. ticker / cik / domain / crd / linkedin_url / UUID → {node_id, node_type, name} over the mars entity DAG — the entry point for traversal (feed node_id to graph_entity / graph_neighbors). Strong-ID first; a bare NAME matches company then institution (resolve investors by crd). When >1 canonical matches, all are in candidates. node_type ∈ company / person / investor / institution ('Duke University' → institution node for the alumni walk). Prototype.

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": {
      "identifier": "<identifier>"
    },
    "name": "graph_resolve"
  }
}

Input Schema

Name	Required	Description	Default
`identifier`	Yes	ticker / cik / domain / crd / linkedin_url / node UUID.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds non-obvious behavior: resolution precedence, that ambiguous matches are returned together in `candidates`, and the node_type taxonomy. It stops short of stating what happens on zero matches or whether results are cached, and the '[beta]'/'Prototype' markers hint at instability without explaining it.

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 structured with the verb, then the mapping, then the traversal hand-off. The opening sentence about being mirrored by the cross-family `resolve` tool consumes space for modest payoff, and heavy bold markup plus the trailing one-word 'Prototype.' add noise, but overall density is high and sentences earn their place.

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?

No output schema exists, but the description compensates by naming the return fields and the `candidates` array for multi-match cases, and it covers the node_type values an agent needs to interpret results. Missing only edge-case behavior (no match, invalid format) for a tool whose complexity is genuinely low.

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% for the single `identifier` param, so the baseline is high. The description still adds real meaning beyond the schema: the precedence rule (strong IDs before names), the company-then-institution fallback for bare names, and the crd-specific investor hint. It does not specify accepted formats (e.g., CIK padding, URL normalization) which would have pushed this higher.

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 and resource ('Resolve any identifier to a canonical graph node') and enumerates exactly which identifier types are accepted (ticker / cik / domain / crd / linkedin_url / UUID) plus the return shape {node_id, node_type, name}. It also distinguishes itself from siblings by naming graph_entity / graph_neighbors as downstream consumers and noting it is mirrored by the shared `resolve` tool.

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 frames the tool as 'the entry point for traversal' and tells the agent what to do next (feed node_id to graph_entity / graph_neighbors). It also gives resolution-order guidance ('Strong-ID first; a bare NAME matches company then institution') and a concrete routing hint ('resolve investors by crd'), which is the kind of when-to-use detail most definitions lack.

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

All Kaleidoscope MCP (SEC & financial data) 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?