Skip to main content
Glama

People Data Labs MCP by usefulapi

Enrich a company

pdl_company_enrich
Read-only

Find the single best-matching company record. Requires a non-ambiguous input — name OR website OR ticker OR profile (website/ticker/profile resolve more reliably than name). Returns firmographics (industry, size, location, etc.) or a 404 'no match' body. API: GET /company/enrich.

Input Schema

NameRequiredDescriptionDefault
nameNoCompany name, e.g. 'People Data Labs'.
pdl_idNoPDL id for a company record.
prettyNoPretty-print the JSON response.
regionNoCompany state / region.
tickerNoStock ticker for a public company, e.g. 'AAPL'.
countryNoCompany country.
profileNoCompany social profile URL, e.g. a LinkedIn company URL.
websiteNoCompany website, e.g. 'google.com' (most reliable).
localityNoCompany city / locality.
locationNoCompany location free-text.
titlecaseNoTitlecase the returned data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral context: the input-must-be-non-ambiguous constraint and the 404 'no match' body on failure. It doesn't touch auth or rate limits, but it exceeds what the annotation provides.

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 the purpose, then input requirement, return shape, and endpoint in a tight sequence. No filler; every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With readOnly annotations covering safety, 100% schema coverage, and no output schema, the description is complete enough: it names the return payload (firmographics) and the failure mode (404). Only minor gaps remain around pagination/field selection, which don't affect correct invocation.

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 coverage is 100%, so the baseline is 3, but the description adds value beyond the schema by specifying that name OR website OR ticker OR profile are the identifying inputs and that website/ticker/profile resolve more reliably than name. That reliability ranking is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Find the single best-matching company record' with firmographics as the payload. This distinguishes it from a broad search, though it doesn't name any sibling tool explicitly. Purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states an input requirement (non-ambiguous input from name/website/ticker/profile) and a resolution-reliability ordering, which is implied guidance on how to invoke correctly. However, there is no explicit 'when to use this vs pdl_company_search or pdl_person_enrich' routing, so usage context is only implied.

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.