Who owns and runs a company, and the questions to ask before you deal with it.
Scored across 3 tools
Each tool has a clearly distinct role: check_company initiates or checks a company report, get_report retrieves report status or content, and list_reports lists recent reports. The descriptions clarify boundaries, including that reading a report uses none of the reader's reports.
All three names follow a consistent verb_noun snake_case pattern: check_company, get_report, list_reports. The convention is predictable and readable.
Three tools are on the low side, but each supports a distinct step in the company-report workflow without redundancy. The narrow scope makes the small surface reasonable.
The surface covers initiating/checking a company report, reading its status or contents, and listing recent reports. Minor gaps exist, such as no explicit cancel/delete or answer-submission operation, but core workflows are covered.
Use this when someone asks about a company or wants one checked. Give the company's name and, if known, its city or country. If a recent report on the company is stored, it comes back at once; otherwise a new report starts and the answer says when it will be ready. A new report uses one of the reader's reports; asking again for the same company does not. When several companies match the name, the answer lists them: ask the reader which one they mean, then call this again with that company's choice token. LightRay checks companies, not people.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The company's name, as it is registered if known: its legal name with its legal form, such as Limited or LLC. | |
| place | No | The company's city or country, if known. It helps find the right company. | |
| choice | No | The choice token of one company from the list this tool returned when several matched. Give it with the same name. |
| Name | Required | Description |
|---|---|---|
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that a new report consumes one of the reader's report quota, that repeats for the same company do not, and that the call can return asynchronously with an ETA. This is consistent with readOnlyHint=false, openWorldHint=true and idempotentHint=false, and it explains the practical consequence of each.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, front-loaded with the trigger condition, then inputs, then return behavior, then the disambiguation loop, then scope exclusion. No filler, and each sentence carries a distinct operational fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description still covers the two return shapes (immediate report vs. queued with ETA) and the multi-match list. An agent has everything needed to call it, interpret the result, and handle the follow-up correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds procedural meaning the schema cannot, notably that the choice token must be supplied together with the same name after a multi-match response. It also frames place as an optional disambiguator ('if known'), reinforcing the schema's intent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('checks companies') and immediately clarifies what 'check' means operationally: a stored recent report is returned, or a new report is started. It never names get_report or list_reports, so the boundary with those siblings (retrieve an existing report vs. trigger/inspect a company) is left for the agent to infer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear when-to-use ('when someone asks about a company or wants one checked'), plus concrete handling for the ambiguous-name case: list matches, ask the reader, re-call with the choice token. It also states an exclusion ('LightRay checks companies, not people'), but does not explicitly route to get_report/list_reports for follow-up retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to see how far a report has got and what has been found so far, or to read a ready report: its date, the main point, any questions to ask, what was found, the next steps, the companies worth a look next and its link. LightRay writes each report: the main point, questions, findings and next steps are LightRay's. Give the report_id that check_company or list_reports returned, or the report's link. Reading a report uses none of the reader's reports.
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes | The report_id that check_company or list_reports returned, or the report's link. |
| Name | Required | Description |
|---|---|---|
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds a genuinely non-annotation fact — 'Reading a report uses none of the reader's reports' — which is a quota/credit disclosure an agent would otherwise have to discover, plus a note on authorship of the content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, which is good. However, the long enumerated list of return fields (date, main point, questions, findings, next steps, companies, link) is verbose and redundant given an output schema exists, diluting the signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with rich annotations and an output schema, the description covers purpose, id provenance, and the quota implication. Nothing an agent needs in order to call it correctly is missing; the field enumeration is surplus rather than necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter at 100% schema coverage, the schema already documents report_id and even that a link is accepted. The description restates this verbatim rather than adding format or edge-case detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('see how far a report has got', 'read a ready report') and covers both lifecycle states (in-progress status vs. finished report). It names the sibling tools (check_company, list_reports) only as id sources rather than as alternatives to avoid, so differentiation is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly frames two use cases — checking progress/findings on an in-flight report and reading a finished one — and tells the agent where the report_id comes from (check_company, list_reports, or the report's link). No explicit exclusion is given, but the routing context is concrete enough to act on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to see the reader's recent reports from here, newest first, each with whether it is ready and its link. It uses none of the reader's reports.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many reports to list, newest first: 1 to 20. 10 if not given. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| reports | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description usefully adds ordering (newest first) and per-item status/link, but the sentence 'It uses none of the reader's reports' is confusing and reads like a garbled statement about arguments rather than a behavioral fact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, but the second is opaque and earns no place — an agent cannot act on 'It uses none of the reader's reports'. The useful content is front-loaded, at least.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return-value detail is redundant rather than necessary. What is missing is scope disambiguation ('from here' — whose reports, which workspace) and any routing versus get_report, so the definition is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the limit parameter already documents range (1-20) and default (10). The description only echoes the 'newest first' ordering, adding nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: see the reader's recent reports, newest first, each annotated with readiness and a link. It is distinguishable from get_report (single report) and check_company, though 'from here' is vague about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to see the reader's recent reports' implies the retrieval scenario but never states when to prefer it over get_report, nor any exclusion or prerequisite. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_companyget_reportlist_reportsConfirm a US business is real and find who controls it. 32.6M official registry records.
Who pays owners for company records, code and datasets, closed companies included. Sourced terms.
UK company register lookups plus US, EU and UN sanctions screening. Every answer cites source.
Follow public corporate ownership
Add one secure layer between your agents and this server.