> For the complete documentation index, see [llms.txt](https://help.delpha.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.delpha.io/delpha-api-and-mcp/mcp/release-notes.md). # Release Notes Every release of the Delpha MCP server, newest first. ## Release notes {% hint style="info" %} The tools themselves are generated from the published Delpha API document, so a change to the API's contract appears in the [Delpha API](https://help.delpha.io/delpha-api-and-mcp/api) documentation and its changelog rather than here. {% endhint %} ### 2026-10-19 * Signing in from Claude Code, Codex, and Cursor now completes. Those clients send the sign-in back to an address on the user's own machine, on a port chosen at the time, and the server now runs the authorization step itself and accepts that address on any port. Its discovery metadata names the server's own authorization and token endpoints, and every authorization response carries the issuer (RFC 9207). Nothing changes for claude.ai and ChatGPT: existing connections keep working without a new sign-in, and the tools, their inputs, and their cost are unchanged. * The console's MCP page lists one connected client per signed-in client — a Claude Code, a Codex, and a Cursor session of the same user are three rows, where the latest sign-in used to replace the previous one. ### 2026-10-12 * `findAndValidatePhone` is now `validateAndNormalizePhone` ("Validate & normalize phone number") and `findAndValidateName` is now `validateAndNormalizeName` ("Validate & normalize person name"). Neither tool ever searched: each checks and normalizes the number or name it is given, and the old names said otherwise. Inputs, results, annotations, and cost are unchanged, and the result tools keep their names (`getPhoneResult`, `getNameResult`). The old names are no longer listed; a call to an old name is still accepted and routed to the new tool for a transition period. ### 2026-09-29 * Every tool's annotations now say what it does, and no tool is annotated read-only. A find-and-validate call spends credits and starts a job (`readOnlyHint: false`, `idempotentHint: false`). A result call adds no charge and returns the same answer when repeated (`idempotentHint: true`), but the read that finds a job finished settles or refunds its charge, so it is not read-only either. `findAndValidateName` reaches no external system (`openWorldHint: false`). * Every tool states what it costs and keeps in its own description, and every find tool's description opens with the input it needs. * Smaller inputs. The website and LinkedIn tools no longer take an email address (the company website carries the same signal), the phone tool takes `country_code` only, and every tool rejects fields it does not declare, including inside the legal-ID `address`, which is the looked-up company's registered address. * Results no longer carry `request_id` or `process_time`, and a submitted job's message no longer names the internal worker. * `findAndValidateUltimateParent` states where its inputs go, and this page's Data sources & privacy section now covers the company tools too. * `getLinkedInProfileResult` now reports an outdated profile URL: `url_changed` is true when the URL you gave was not found while exactly one other matching profile was, and `suggested_url` names it. The URL you submit for validation is no longer requested. ### 2026-09-23 * Tools are listed company identity first — ultimate parent, website, legal ID, LinkedIn company page — then the contact tools: email, phone, name, LinkedIn profile. Tool names and the count (16) are unchanged. * Every find-and-validate tool now reports `idempotentHint: false`: repeating a call with the same input starts a new job and a new charge. The result tools are unchanged — re-reading a result never re-runs or re-charges the job. * The server instructions now say what each tool family validates, how a find call and its result call work together, what a call costs and keeps, and Delpha's role for the data. That is stated once instead of in every tool description, and the references to the `Idempotency-Key` header and to test mode, which an MCP client cannot use, are gone from the tools. * LinkedIn results report their label as `OK` instead of `Ok`, the spelling every other result uses. Update any exact comparison against `"Ok"`. * The result cards no longer show a Continue button. * This page gains a Data sources & privacy section: where each people tool's result comes from, what leaves Delpha, Delpha's role, and a contact for anyone whose data was checked. ### 2026-09-16 * The hosted Delpha MCP server is generally available at `https://mcp.delpha.ai/mcp` (Streamable HTTP). * 16 tools, generated from the published Delpha API document: eight find-and-validate tools (email, phone, name, website, legal ID, LinkedIn profile, LinkedIn company page, ultimate parent) and the eight result tools that return each verification's outcome. * Two ways in: sign in with your Delpha account (OAuth 2.1 with PKCE), or a live API key sent as `Authorization: Bearer dlp_…`. Access is bound to your Delpha team; a key's scopes and credit ceiling apply to tool calls exactly as they do on the API. * Test-mode API keys are refused with `403 sandbox_key_unsupported` — the server serves live keys only. * Each of the eight result tools renders an interactive result card in ChatGPT. * Withdrawn together with API document 2.0.0: the LinkedIn import tools (`submitLinkedinImport`, `getLinkedinImportResult`). The combined LinkedIn find-and-validate tool had already been replaced by the profile and company-page tools. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.delpha.io/delpha-api-and-mcp/mcp/release-notes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.