Clarifo

resolve_entities

Read-onlyIdempotent

Resolve a batch of company names/tickers to canonical entities.

Use this before running per-company analysis on a list, so the downstream loop drives off CIKs/canonical names rather than the user's raw strings (avoiding the per-tool fuzzy-match drift that used to put two companies into a single research_company response).

The resolver is cached, so a hot list — say the same five S&P 500 industrials called repeatedly — costs effectively zero on the second invocation.

Args: companies: List of inputs to resolve (max 50; entries beyond the first 50 are ignored). Each entry can be a ticker ("DHI", "AAPL"), an official name ("HORTON D R INC /DE/"), or a brand name ("D.R. Horton", "Google"). Order is preserved in the response. query: Instead of companies: a partial name or ticker as typed ("kon", "nok"). Returns up to limit ranked candidates ({"suggestions": [{name, display_name, ticker, display_ticker, market}]}) for a search box, Nordic and US in one relevance order. Use companies to resolve. limit: Candidates for query (1-20, default 8).

Returns: { "resolved": [ { "input": "DHI", "name": "HORTON D R INC /DE/", "cik": "0000882184", "ticker": "DHI", "market": "us", "confidence": 1.0, "source": "ticker_exact" }, ... ], "unresolved": ["TOTALLY_UNKNOWN_TICKER"], "total": 6, "matched": 5 }

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "resolve_entities"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`companies`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so behavior beyond that is what matters, and the description delivers: a hard cap of 50 entries with the explicit consequence that extras are silently ignored, order preservation, and caching that makes repeat invocations effectively free. It does not state failure behavior when nothing matches, though the during resolved/unresolved split is shown implicitly.

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 purpose and the when-to-use rule before any parameter detail, and each section earns its place. The Returns block is somewhat redundant given an output schema exists, though the concrete example does clarify confidence/source fields that the schema alone would not make obvious.

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?

A tool with an output schema, no required params, and two mutually exclusive modes is exactly the case where mode selection and bounds need spelling out, and this definition does that plus documents truncation and cache behavior. Nothing an agent needs in order 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.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and carries no descriptions or enums, so the description must do all the work, and it does: each of the three parameters gets format examples, accepted input classes (ticker, official name, brand), bounds (max 50, limit 1-20 with default 8), and the semantic distinction between resolving and suggesting. This is meaningfully more than the bare types in the schema.

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?

Opens with a concrete verb+resource: "Resolve a batch of company names/tickers to canonical entities." It also names the downstream consumer (research_company) whose fuzzy-match drift this tool prevents, which lets an agent distinguish it from the analysis siblings without opening either schema.

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 states the ordering rule: use this **before** running per-company analysis on a list, and explains why (downstream loop should drive off CIKs/canonical names). It also disambiguates the two mutually exclusive modes, telling the agent to use ``companies`` to resolve and ``query`` only for search-box ranking.

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

All Clarifo 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.