Give an assistant useful tools—not a database bypass.

Connect an MCP-compatible client to https://peopledat.com/mcp. Authenticate with a workspace-bound pd_test_… or pd_live_… API key in the Bearer authorization header.

• Stateless Streamable HTTP transport.
• Workspace-scoped tools and results.
• The same key scopes, entitlement checks, rate limits, exclusions, and credit ledger as REST.
• Privacy-safe request auditing without raw addresses, request bodies, raw IPs, or credentials.
• Deterministic free scenarios for test keys.
• Explicit idempotency and maximum-credit authorization for billable tools.

1. 1

   Create a test key

   In Dashboard → Developer, create a pd_test_… key and select only the scopes needed for your first tools. Copy it once into your password manager.
2. 2

   Add the remote server

   In your client’s remote/Streamable HTTP MCP settings, use https://peopledat.com/mcp as the server URL.
3. 3

   Set Bearer authentication

   Configure an Authorization header whose value is Bearer pd_test_…. Do not place the key in the URL.
4. 4

   Reload tools

   Reconnect or refresh the MCP server, then confirm that the expected PeopleDat tools appear.
5. 5

   Start with a read tool

   Call credit_balance or recent_jobs before trying verification.

{
  "name": "peopledat",
  "url": "https://peopledat.com/mcp",
  "transport": "streamable-http",
  "headers": {
    "Authorization": "Bearer pd_test_REPLACE_WITH_YOUR_KEY"
  }
}

Configuration names differ between MCP clients. The required facts are the HTTPS endpoint, Streamable HTTP support, and the Bearer header.

1. 1

   Estimate a batch

   Call estimate_bulk_work with a few reserved peopledat.test records. The estimated maximum is zero for a test key.
2. 2

   Verify one scenario

   Call verify_one with [email protected], idempotency_key of at least eight characters, and max_credits: 0.
3. 3

   Exercise every result

   Use catch-all, role, disposable, spam-trap, full, invalid, disabled, and unknown before live traffic.
4. 4

   Repeat the same request

   Reuse the exact idempotency key and input to confirm you receive the original outcome rather than duplicate work.

{
  "email": "[email protected]",
  "mode": "power",
  "reference": "crm-contact-42",
  "idempotency_key": "mcp-test-contact-42-v1",
  "max_credits": 0
}

verify_one requires a unique idempotency_key and max_credits: 1 for live work. create_bulk_job requires a key plus a maximum at least equal to the submitted record count. This deliberately authorizes the worst-case conclusive charge; unknown and excluded results still use zero credits.

{
  "name": "Weekly CRM hygiene",
  "mode": "power",
  "records": [
    { "email": "[email protected]", "reference": "crm-101" },
    { "email": "[email protected]", "reference": "crm-102" }
  ],
  "idempotency_key": "weekly-crm-2026-08-30",
  "max_credits": 2
}

The bulk tool returns a pending job. Use job_status until it reaches a terminal state, then use job_results with its cursor. Do not ask an assistant to resubmit just because a job is still processing.

• Store API keys in the client’s secure secret store, never in a prompt, repository, screenshot, or shared transcript.
• Start with test keys and the minimum scopes.
• Use a separate key per client/integration so revocation and attribution stay clear.
• Lower per-minute limits and set a daily credit cap for unattended assistants.
• Require human review for expensive bulk actions in the client workflow.
• Revoke a key immediately if its one-time secret is exposed.