Skip to main content
Glama

peopledatalabs

by io.usefulapi

Autocomplete search values

pdl_autocomplete
Read-only

Get suggested values for a search field along with the number of available records for each — useful for building valid Person/Company Search queries. Free on all plans. API: GET /autocomplete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoMax suggestions to return. Default 10.
textNoPartial text to get suggestions for, e.g. 'stanf'.
fieldYesField to autocomplete: e.g. company, school, location, region, country, industry, title, role, sub_role, skill, major.
prettyNoPretty-print the JSON response.
titlecaseNoTitlecase the returned data.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

The annotation already marks this as read-only, and the description reinforces this with 'API: GET /autocomplete' and 'Free on all plans.' It also discloses return behavior by mentioning suggested values and available record counts, adding value beyond the structured annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no filler. The primary purpose is front-loaded, and the extra details (free tier, API method) are brief and useful for invoking the tool correctly.

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?

Despite having no output schema, the description explains what the response contains (suggested values and record counts) and why the tool matters. For a low-complexity autocomplete tool with rich parameter schema and a read-only annotation, this is sufficient for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters with examples. The description does not add much parameter-specific meaning, but it also does not need to because the schema carries the detail.

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?

States a specific verb and resource: 'Get suggested values for a search field' with the added benefit of record counts. It is clearly distinct from the search/enrichment sibling tools because it is an autocomplete endpoint for building valid queries.

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?

Explicitly mentions it is useful for building valid Person/Company Search queries, giving a clear context for when to use it. It does not formally name alternatives or exclusion conditions, but the intended usage is evident from the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All peopledatalabs toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool targets a clearly distinct operation: person enrichment, person identify, person search, company enrichment, company search, IP enrichment, job posting search, and autocomplete. Even the closely related person tools are explicitly differentiated by match semantics (1:1, up to 20 ranked, open-ended search).

Naming Consistency5/5

All tools follow a consistent pdl_<entity>_<operation> pattern with snake_case names, making the tool surface predictable. The only slight deviation is pdl_autocomplete, but it still fits the overall style cleanly.

Tool Count5/5

Eight tools is well-scoped for a people-data and company-data platform. Each tool covers a distinct data access pattern without redundancy or unnecessary bulk.

Completeness5/5

The tool set covers the core read-only workflows for the domain: person lookup, person identification, person search, company lookup, company search, IP enrichment, job posting search, and query-building autocomplete. No obvious dead ends or missing critical operations are apparent.

Resources