Skip to main content
Glama

Search companies

search_companies
Read-onlyIdempotent

Find a company by name or identifier. The query can be a scheme-prefixed identifier such as lei:5493001KJTIIGC8Y1R12, a bare registration number (CRN, CIK, LEI and similar shapes), or a company name (matched exact, then prefix, then token, then fuzzy). Hits carry the graph node_id that entity_risk_profile takes, plus jurisdiction, status fields, and register identifiers. connected_sources names the registers an empty result was searched against. Companies only; persons are never returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum hits, default 10, maximum 25.
queryYesCompany name, scheme:value identifier, or bare number.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral insight beyond annotations: the exact matching order, that connected_sources is populated for empty results, and that persons are excluded. It also clarifies that hits include jurisdiction/status/register identifiers. This goes beyond structured hints, though it doesn't disclose return structure in detail (no output schema), so a 4 is appropriate.

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?

The description is a single paragraph of moderate length (about 90 words). It front-loads the core purpose in the first sentence, then efficiently covers matching behavior, output fields, and exclusion criteria. While dense, every sentence contributes value; it is structured and avoids fluff. Could be split for readability but remains appropriate and not overwritten.

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?

With no output schema, the description compensates by explicitly enumerating the fields returned (node_id, jurisdiction, status, register identifiers) and the behavior of connected_sources on empty results. It also states the limitation to companies. Combined with a complete input schema and clear annotations, an agent has all necessary information to know what the tool returns and how to use it effectively.

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 description coverage is 100%, with both 'query' and 'limit' described. The description enhances understanding by detailing query syntax variations (scheme-prefixed, bare number, exact/prefix/token/fuzzy matching) and by noting that limit defaults to 10 with max 25 (already in schema, but reinforced). It adds semantic nuance beyond raw parameter names, such as that bare registration numbers are accepted and how matching is prioritized.

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 states the tool's purpose: 'Find a company by name or identifier.' It specifies the accepted query forms (scheme-prefixed identifier, bare number, company name), distinguishes itself from sibling search tools by noting 'Companies only; persons are never returned,' and explicitly mentions the output's key field (node_id) for downstream use. This is a specific verb plus resource, effectively differentiating from related tools.

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 provides detailed usage context for the query parameter: matching precedence (exact, prefix, token, fuzzy), accepted input shapes, and the result structure. It implicitly guides when to use the tool (to obtain a node_id for entity_risk_profile) but does not explicitly contrast with alternative search or profile tools. While not stating 'when not to use,' the clear resolution and output semantics imply appropriate contexts, so it is slightly above average but missing explicit alternatives.

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