company-enrichment
Server Details
Enrich any domain into a full company profile with firmographics and buying signals.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- DataLeadsPRO/company-enrichment
- GitHub Stars
- 0
- Server Listing
- company-enrichment
TDQS
Scored across 2 tools
The two tools are distinguishable in name ('company' vs 'company_signals'), but the sparse descriptions create some ambiguity about whether company data includes signals or whether they must be fetched separately.
Both names use lowercase snake_case and share the 'company' prefix, showing a consistent pattern. The singular 'company' and plural 'company_signals' is a minor deviation but still readable and predictable.
Two tools feels too thin for a company enrichment service, which typically involves multiple operations such as search, lookup, signals, and possibly financial or people data. The narrow surface may force agents into too-coarse calls.
The domain is implicitly company data enrichment, but only two endpoints exist with no obvious support for searching, filtering, or expanding beyond basic company and signals. Major enrichment capabilities appear absent.
Available Tools
2 toolscompanyDInspect
V1 Company
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| maxTimeout | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'V1 Company' reveals nothing about side effects, return values, permissions, or operational behavior.
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?
The description is extremely short, but this is under-specification, not conciseness. It does not contain a single substantive sentence that 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?
With no annotations, no output schema, no parameter descriptions, and a sibling tool to disambiguate, the definition is completely inadequate for an agent to invoke the tool 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 description coverage is 0%, and the description does not compensate by explaining url or maxTimeout. The agent is left with only parameter names and types, with no indication of purpose, format, or constraints.
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 'V1 Company' is a tautology that restates the tool name and a version marker; it contains no verb or resource indicating what the tool actually does. There is no differentiation from the sibling company_signals.
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 about when to use this tool versus company_signals or any other alternative. The description provides no context, prerequisites, or exclusions that would help an agent choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_signalsDInspect
V1 Company Signals
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| maxTimeout | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it says nothing about side effects, data access, timeouts, or response behavior.
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?
Extreme under-specification: the description is a single vague phrase that provides no operational content. This is not concise; it is empty.
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 tool with two parameters, no annotations, no output schema, and an unclear relationship to a sibling, this description is wholly inadequate 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?
Two parameters (domain and maxTimeout) exist with zero schema description coverage. The description does not mention either parameter or their semantics, so agents cannot determine how to populate them.
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 'V1 Company Signals' is a label rather than a functional description. It names the tool but provides no verb, resource, or explanation of what the tool does, and does nothing to distinguish it from the sibling 'company'.
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 about when to invoke this tool, what signals it returns, or how it relates to the sibling 'company'. The agent is left entirely without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
company - First observed
company_signals
Related MCP Connectors
Domain & brand intelligence: company enrichment, tech stack detection, brand research.
TAM mapping, company discovery, contact intelligence, and technographics across 65M+ B2B domains.
Enrich contacts by email or LinkedIn URL and build targeted B2B audiences.
Enrich first-party lists with live intent, activity, and inbox signals for marketing and outreach.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceEnriches B2B company profiles with structured data including firmographic, technographic, and intent signals.-
- AlicenseAqualityAmaintenanceEnables enriching company domains into structured firmographics including employee band, industry, HQ, founded year, revenue estimate, logo, and description, with source provenance and data completeness scoring.155 npm1MIT
- AlicenseAqualityCmaintenanceEnables enrichment of company domains with verified firmographic signals including tech stack, hiring activity, email infrastructure, and SOC 2 compliance, returning compact typed JSON for AI agents.36 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnriches company data from a domain name, providing firmographics, socials, tech stack, and contact info via a pay-per-call x402 micropayment API.2MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.