Model Context Protocol

An MCP Server for Deep Linking

Setting up Universal Links is not hard, it is fiddly: half a dozen identifiers living in different consoles, a file that has to be at an exact path with an exact content type, and a failure mode that produces no error at all. That is a bad afternoon for a person and an excellent task for an agent. DeepTap ships a hosted MCP server so Claude Code or Codex can do the whole hosted side — and then check that it actually worked.

claude mcp add --transport http deeptap https://deeptap.io/api/mcp
OAuth 2.1 · nothing to install · no API key to paste

Published 2026-08-26 · Last updated 2026-08-26

Why deep linking suits an agent

Three properties make a task worth handing to an agent: the steps are tedious but well-defined, the inputs are scattered across places a human has to go hunting for, and the result is machine-checkable. Deep-link setup has all three, and the third is the one that usually decides it.

Consider what a person actually does. Find the Team ID in the Apple Developer portal. Find the bundle ID in Xcode. Find the SHA-256 fingerprint in Play Console — and pick the right one, because with Play App Signing the certificate that ends up on devices is the one Google holds, not your upload key. Decide which paths the app claims. Get the file served at an exact path with a JSON content type and no redirect. Add the entitlement, add the intent filter, ship, and hope.

Now consider the failure mode. Since iOS 14 the association file is fetched by Apple's CDN when your app is installed or updated, not on every tap. A wrong content type or a stray redirect does not raise an error anywhere — Universal Links just quietly stop opening your app for everyone who installed during that window. Your own phone has a working association cached, so you cannot reproduce it.

A task where the mistakes are invisible is exactly the task you want something to check for you.

What the agent can do

Six tools. No dashboard round-trips.

get_account

Reads the plan, current usage and rate limits, so the agent knows what it is allowed to create before it tries.

list_domains

Lists every deep-link domain with its iOS and Android configuration, association-file URLs and deferred-link endpoint.

get_domain

Full configuration for one domain, including the URL your app calls on first launch to claim a deferred link.

create_domain

Creates a domain from a subdomain label and, optionally, the iOS and Android settings in the same call.

update_domain

Partial merge of iOS and Android settings. Omitted fields are preserved, and first-time platform configuration is rejected if required identifiers are missing rather than silently written half-configured.

verify_domain

Fetches the live association files and returns a structured pass/fail report: reachability, content type, JSON validity, and whether the declared app IDs and fingerprints match the configuration.

The part that makes it worth doing

An agent that can only write configuration is a fancy form. An agent that can verify its own work closes the loop. verify_domain makes the server fetch the live files and returns a structured report per check — so a failure is something the agent can read, act on, and re-test, instead of something you find out about from a user three weeks later.

verify_domain → {
  "apple_app_site_association": [
    { "check": "reachable",     "passed": true,  "detail": "HTTP 200" },
    { "check": "content_type",  "passed": true,  "detail": "Content-Type: application/json" },
    { "check": "valid_json",    "passed": true },
    { "check": "app_id",        "passed": false, "detail": "File declares ABCDE12345.com.example.staging,
                                                            configuration expects ABCDE12345.com.example.app" },
    { "check": "paths",         "passed": true }
  ],
  "assetlinks": [ … ]
}

That fourth line is a real bug — a staging bundle ID left in a production configuration — and it is the kind that survives code review, ships, and breaks Universal Links for every new installer without a single error message. Here it is a failed check the agent can fix in the same turn.

What it looks like in practice

> set up deep links for my app on myapp.deeptap.io

I'll need your app identifiers. Let me check what's already configured.

· get_account → plan: indie, 1 of 3 domains used

· create_domain → myapp.deeptap.io

I found your Team ID and bundle ID in the Xcode project, and the package name in build.gradle. For Android I need the SHA-256 from Play Console → Release → Setup → App Integrity — the app signing key, not the upload key.

> [pastes fingerprint]

· update_domain → ios + android configured

· verify_domain → 9 of 10 checks passed

⚠ app_id mismatch — the file declares com.example.staging

Your Xcode project has a staging bundle ID on the active scheme. Using the release value from the target instead.

· update_domain → ios.bundle_id corrected

· verify_domain → all checks passed

Hosted side is done. I've added the Associated Domains entitlement and the intent filter to your project. Note that devices with the app already installed keep their current association until the app updates — new installs pick this up immediately.

Illustrative, not a recording. The tool calls, the check names and that closing caveat are the real behaviour — update_domain returns that warning itself.

Where the boundary is

The MCP server handles

  • • Creating and configuring the domain
  • • Generating and serving both association files
  • • Certificates and correct headers
  • • Verifying the live files against your config
  • • Reading back plan limits and current usage

Still your project

  • • The Associated Domains entitlement in Xcode
  • • The intent filter in your Android manifest
  • • Routing an incoming URL to a screen
  • • The one call for deferred links on first launch

Worth saying plainly: the right-hand column is code in your repository, and a coding agent is perfectly capable of writing it. The MCP server is not a substitute for that — it is the half the agent could not otherwise reach, because it lives on our side of the network.

Two minutes to try it

claude mcp add --transport http deeptap https://deeptap.io/api/mcp

Sign in through the browser when prompted. Then ask your agent to set up a domain. Plans start at $5.99 a month with a 7-day free trial.

Frequently asked questions

What is the DeepTap MCP server?

A hosted Model Context Protocol endpoint at https://deeptap.io/api/mcp that exposes six tools for creating and verifying deep-link domains. Any MCP client can use it — Claude Code, Codex, Claude Desktop. It is remote, so there is nothing to install and no package to keep updated.

How does authentication work?

OAuth 2.1. The client opens a browser, you sign in and approve, and that is it — there is no API key to generate, paste into a config file, or accidentally commit. Revoke access from the dashboard whenever you want.

How do I add it to Claude Code?

claude mcp add --transport http deeptap https://deeptap.io/api/mcp — then ask for what you want. The full setup guide covers Codex and Claude Desktop as well.

Can the agent tell whether the setup actually worked?

Yes, and this is the part that matters most. verify_domain makes the server fetch your live apple-app-site-association and assetlinks.json and return a structured report on each check. The agent can act on a failed check and re-verify rather than declaring success and leaving you to find out from users.

What can the agent not do?

It cannot touch your app. Adding the Associated Domains entitlement in Xcode, adding the intent filter to your manifest, and writing your routing code are all in your project, not ours — though a coding agent is of course perfectly capable of editing those files directly. The MCP server covers the hosted side: the domain, the identifiers, the files and the verification.

Do other deep-linking platforms offer an MCP server?

Not as far as we know. Deep linking is unusually well suited to it — the work is a sequence of steps with a machine-checkable result — but the established measurement platforms are built around dashboards for marketers rather than tool surfaces for agents.

Is there a REST API too?

Yes, with a machine-readable OpenAPI 3.1 spec, if you would rather script it than converse with it. The MCP server and the REST API cover the same ground; MCP is the one an agent can discover and use without you writing the integration.