Search AI infrastructure, inspect facility evidence and explore sourced company relationships.
Scored across 3 tools
Each tool targets a distinct resource or operation: get_company fetches company details and relationships, get_facility fetches facility details, and search_infrastructure is for discovery. There is no overlap in purpose, and an agent can easily choose the right tool.
All tool names follow a clear verb_noun pattern: get_company, get_facility, search_infrastructure. The verbs get and search are used consistently for their respective operations.
With only 3 tools, the set is minimal but covers the core read operations for a data retrieval server. It is at the low end of the typical 3-15 range, so slightly thin but still reasonable for the scope.
The surface allows searching and retrieving companies and facilities, but lacks a direct way to get a facility's relationships (only company relationships are available). There is also no enumeration or listing without a search term, which may cause gaps for browsing.
Read a company and a page of published supplier, customer, ownership, investment, or facility relationships. Company verification dates are unknown. Each upstream relationship category is capped at 500.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| limit | No | ||
| offset | No | ||
| relationship | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive semantics, yet the description adds two genuinely useful behavioral facts: verification dates are unknown (a data-quality caveat) and each upstream relationship category is capped at 500 (a hard result ceiling). It stops short of explaining pagination mechanics despite implying 'a page'.
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 tightly packed sentences with no filler; the cap constraint and data caveat are stated crisply and nothing is repeated from the schema or annotations.
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 read tool with no output schema, the description covers scope, result ceiling, and a data-quality caveat. The main omission is any sense of what a relationship record or page envelope looks like, but overall it is sufficient for correct invocation.
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 description coverage is 0%, so the description must carry the load. It translates the terse enum values (holds, heldBy, sites) into human terms (ownership, investment, facility), which is real added meaning, but it says nothing about slug format, limit, or offset beyond the implicit notion of a 'page'.
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?
States a specific verb (Read) and resource (a company plus a page of relationships), and enumerates the relationship classes it returns. It is clear what the tool does, though it never explicitly contrasts itself with get_facility or search_infrastructure.
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?
There is no guidance on when to use this versus the sibling tools or when not to use it. Usage can only be inferred from the verb 'Read' and the resource 'company'. No prerequisites or conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one published facility by slug, including canonical URL, sourced facts, and actual verification date. At most 20 source links; no quotes, imagery, geometry, or market series.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered; the description goes further by disclosing the return scope (max 20 source links) and explicitly listing what is NOT returned (quotes, imagery, geometry, market series). That prevents the agent from requesting data this endpoint cannot supply.
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 sentences, zero filler, with the core action front-loaded and the inclusion/exclusion lists packed into the second sentence. Every clause carries information an agent can act on.
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 no output schema, the description correctly takes on the burden of describing the payload and its limits, which it does well. It does not address behavior for a non-existent or unpublished slug, which is the only notable omission for a single-resource read.
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?
Only one parameter, and the schema already encodes its format via pattern and length constraints at 0% description coverage. The description adds the meaningful subtlety that the slug must reference a *published* facility, but no syntax or format detail beyond that.
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?
States a specific verb and resource ('Read one published facility by slug') and enumerates the payload (canonical URL, sourced facts, verification date). It is clearly a single-entity lookup distinct from search_infrastructure, though it never names the siblings it differs from.
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?
'Read one published facility' and the 'by slug' phrasing imply a singular fetch rather than a search, which hints at when to prefer it over a search tool. However, no explicit when-to-use, when-not-to-use, or alternative tool is named, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published facility and company names, slugs, operators, localities, and country codes. Literal text search with bounded pagination; no arbitrary SQL or URL fetching.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | all | |
| limit | No | ||
| query | Yes | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds genuinely new behavioral context: the search is literal (no query-language semantics) and results are bounded by pagination, and it explicitly rules out arbitrary SQL or URL fetching.
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 tight sentences with no filler. The scope of searchable fields is front-loaded and the safety constraint follows efficiently; every clause earns its place.
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?
Adequate for a read-only search tool with fully annotated safety semantics, but it omits what the results look like (no output schema exists) and says nothing about the kind/limit/offset controls, so an agent must infer result shape and pagination behavior entirely from the input schema.
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 description coverage is 0% and the description mentions no parameters at all. It lists the fields that text can match, but never connects them to 'query', nor explains what 'kind', 'limit', or 'offset' do. With four undocumented parameters and no output schema, the description fails to compensate for the coverage gap.
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?
States a specific verb ('search') plus the resource and the exact searchable fields (facility/company names, slugs, operators, localities, country codes). It is distinguishable from get_company/get_facility by the discovery-vs-retrieval verb, but the description never acknowledges the siblings, so the differentiation is implicit rather than stated.
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?
Usage is only implied: 'literal text search' signals keyword discovery rather than lookup-by-ID, which is the natural counterpart to get_facility/get_company. There is no explicit when-to-use statement, no exclusion of the sibling retrieval tools, and no guidance on choosing between the 'all'/'facilities'/'companies' kinds.
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.
get_companyget_facilitysearch_infrastructureSource-linked enterprise AI deployment search. Free preview; API keys unlock full results.
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
Search declassified UAP/UFO government archives, geocoded sightings and cited entity profiles.
AI compute infrastructure intelligence: facilities, supply chains, sovereign AI, export controls.
Add one secure layer between your agents and this server.
