openpeoplerouter
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DINQ_API_KEY | No | Your DINQ API key for the optional hosted provider. | |
| HUNTER_API_KEY | No | Your Hunter API key. | |
| TIKHUB_API_KEY | No | Your Tikhub API key. | |
| OPENPEOPLEROUTER_TOKEN | No | A long random secret required to protect the HTTP transport when not binding to localhost. | |
| OPENPEOPLEROUTER_PROVIDERS | No | Optional allowlist of providers that may be called, e.g. hunter,tikhub,openalex. If not set, all configured providers are available. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| capabilitiesA | List unified capabilities, inputs and configured providers. No provider request. |
| people_searchA | A list of people you did not have: from a description — a role, a company, a place — or from a source that names them, such as a repository, a paper, a Scholar profile or a company page. Use vendor to pin a provider. Returns outcome, normalized output, raw provider data and _meta.tried. Provider API charges are billed directly to your provider account. |
| companies_searchA | Find companies by a free-text description, a name, an industry, a technology they use, or a domain — provider-native rows in |
| people_enrichB | Everything known about one person: title, employer, location, profile links. Use vendor to pin a provider. Returns outcome, normalized output, raw provider data and _meta.tried. Provider API charges are billed directly to your provider account. |
| companies_enrichB | Enrich a company from its domain, name, LinkedIn URL or a work email — treg picks the provider and names the one that served Use vendor to pin a provider. Returns outcome, normalized output, raw provider data and _meta.tried. Provider API charges are billed directly to your provider account. |
| people_from_imageB | Where a photo appears on the web, and who it is: pages carrying the exact image, and the social profiles among them. Use vendor to pin a provider. Returns outcome, normalized output, raw provider data and _meta.tried. Provider API charges are billed directly to your provider account. |
| social_profileA | One person's public profile on whatever platform a handle belongs to: LinkedIn, X, Instagram, TikTok, YouTube, GitHub and the rest. Give a profile URL, or a platform and a handle. Use vendor to pin a provider. Returns outcome, normalized output, raw provider data and _meta.tried. Provider API charges are billed directly to your provider account. |
| people_identity_resolveA | Identity resolution: one person's profiles across platforms, resolved into a single set. Give any one of them — LinkedIn, GitHub, X, Hugging Face, Scholar, an email — and get the rest. Use vendor to pin a provider. Returns outcome, normalized output, raw provider data and _meta.tried. Provider API charges are billed directly to your provider account. |
| people_contact_findA | How to reach one person: their work email, their phone when you ask for it, and whether an address you already hold is real. Use vendor to pin a provider. Returns outcome, normalized output, raw provider data and _meta.tried. Provider API charges are billed directly to your provider account. |
| find_toolA | Find provider endpoints when unified capabilities cannot meet the need. Searches API metadata, not people. |
| endpointA | Inspect an endpoint's arguments, provider documentation and availability before calling it. |
| call_toolB | Execute a discovered endpoint using your provider key. Provider charges may apply. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
The people_* family is mostly distinct, but social_profile, people_enrich, and people_identity_resolve all accept a single person identifier and return profile-related data, so an agent needs to read descriptions carefully. The meta tools (find_tool, endpoint, call_tool) are clearly separated.
Most domain tools follow a clear people_/companies_ prefixed snake_case pattern. Minor deviations include social_profile lacking the people_ prefix and meta tools mixing noun forms (capabilities, endpoint) with verb_noun forms (find_tool, call_tool).
12 tools is well within the ideal range for a multi-provider data router: 8 domain operations plus 4 discovery/execution tools. Each tool has a clear role, and none feel redundant.
People workflows are comprehensively covered: search, social profile, enrich, identity resolution, contact finding, and image-based lookup. Companies have search and enrich, and the capabilities/find_tool/endpoint/call_tool layer prevents dead ends by allowing access to provider-specific endpoints.