LINKSPREED Releases UIID v2.13 with Native MCP Server and Captcha-Free Agent Onboarding

October 26, 2026 — LINKSPREED today announced the release of UIID v2.13, the newest version of its privacy-first sovereign identity platform. The release is built around a native Model Context Protocol (MCP) server. It gives AI platforms and autonomous AI agents a standardized way to work with UIID identities. Version 2.13 also adds zero-trust cryptographic authentication for aliases, inline captcha support for passkeys, an extended skill.md protocol for agent onboarding, improved OIDC and OAuth discovery behind reverse proxies, and granular MCP security controls.

The full release is available now at uiid.me.

AI agents can act, but they still cannot say who they are

AI models can now write code, read contracts, plan trips and carry out multi-step tasks. Many of them can call external tools without a human watching each step. One question has received far less attention than model capability: who is the agent acting for, and how can anyone check that?

Today, an agent that wants to use a service usually does one of three things:

It borrows the user’s password or browser session.
It uses a long-lived API key that someone pasted into a configuration file.
It pretends to be a human and clicks through the same forms, including captchas.

None of these is a real identity model. They are workarounds. They give agents too much power, make accountability difficult, and leave the owner with no clean way to see what an agent is doing or to take its access away.

UIID v2.13 offers a different approach. An agent gets an identity of its own. That identity is linked to a person or an organization that owns it. The agent receives only the permissions it needs, and the owner can withdraw them at any time. The agent proves what it has to prove with cryptography instead of shared secrets.

What UIID is

UIID is LINKSPREED’s sovereign identity layer. The principle is simple: a person should own their identity, decide what to share, and be able to act in different contexts without handing over more data than necessary.

UIID provides:

A profile and verified identity that the user controls.
Aliases and vaults, so a user can act under a pseudonym or a context-specific persona and keep data per alias.
Passkey sign-in and cryptographic proofs instead of shared secrets.
Badges and credentials that can be requested, issued and verified.
A wallet for micro-transactions.
Shared storage buckets for groups of people.
Organization and enterprise features such as employee credentials and webhooks.

Version 2.13 makes these capabilities reachable by AI systems through an open protocol, with permissions that remain under the owner’s control.

What the Model Context Protocol is, and why it matters here

The Model Context Protocol (MCP) is an open protocol introduced by Anthropic. It standardizes how AI applications connect to external tools, data and prompts. Before MCP, every integration between a model and a service was custom work. With MCP, a service describes what it offers once, and any MCP-capable client can use it.

MCP is based on JSON-RPC 2.0 and has three main building blocks:

Tools are functions the model can call, such as creating an alias or reading a wallet balance.
Resources are readable data the client can load as context, such as a profile or a list of aliases.
Prompts are reusable prompt templates a server can offer to the client.

A session starts with an initialize handshake. In it, client and server agree on a protocol version and exchange capabilities. After that, the client can list what the server offers, for example with tools/list, and use it, for example with tools/call.

UIID v2.13 implements the MCP 2024-11-05 specification. Any compatible client can therefore connect, including Google Gemini, Anthropic Claude, custom LLM applications and autonomous AI agents.

The MCP server is part of the UIID platform itself, not a separate adapter. The identity layer stays the single source of truth. An agent does not receive a copy of someone’s identity. It receives controlled access to the real thing, inside limits that the owner sets.

The MCP endpoints in detail

The MCP server offers three transport endpoints. A fourth endpoint, the OIDC discovery document, was improved in the same release and matters for anyone who hosts UIID behind a proxy or on a custom domain.

Endpoint	Type	Purpose
`/mcp`	HTTP POST	Direct JSON-RPC requests and responses
`/mcp/sse`	Server-Sent Events	Long-lived stream from server to client
`/mcp/messages`	HTTP POST	Session channel for client messages
`/.well-known/openid-configuration`	HTTP GET	OIDC and OAuth discovery with dynamic domain resolution

1. /mcp: direct HTTP POST

/mcp is the main entry point. A client sends MCP messages as JSON-RPC 2.0 requests over HTTP POST, and the server replies with the matching JSON-RPC response. It is the simplest way to integrate, and it suits several cases:

Backend services and scripts that want to call a UIID tool once and read the result.
Custom LLM applications that run their own tool-calling loop.
Testing and debugging, because a single HTTP request is easy to reproduce.

A session begins with the standard handshake. The message below shows the general shape defined by the MCP 2024-11-05 specification. The exact client name and capabilities depend on your client.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {},
    "clientInfo": {
      "name": "my-agent",
      "version": "1.0.0"
    }
  }
}

After the handshake, the client can discover the 25 UIID tools:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list"
}

It can then call one of them through tools/call. The same endpoint also handles the prompt and resource methods that UIID supports.

2. /mcp/sse: Server-Sent Events streaming

Some MCP clients expect a long-lived connection instead of one-off requests. For them, UIID provides a Server-Sent Events endpoint at /mcp/sse. In the HTTP+SSE transport defined in the 2024-11-05 specification, the flow works like this:

The client opens a connection to the SSE endpoint.
The server keeps the stream open and uses it to push messages to the client.
The server tells the client where to send its own messages, which is the session channel.

Streaming is useful when responses are not instant, or when the server needs to notify the client of something. It also matches how many existing MCP clients are built, so they can connect to UIID without adaptation.

3. /mcp/messages: the session channel

/mcp/messages is the session channel that belongs to the SSE connection. While /mcp/sse carries messages from the server to the client, /mcp/messages is where the client sends its JSON-RPC messages back.

Together, /mcp/sse and /mcp/messages form the complete two-way transport described in the specification. The split is intentional: one channel for the stream and one for the requests. Clients that follow the standard pattern need no special handling.

4. /.well-known/openid-configuration: discovery that works behind proxies

UIID acts as an OIDC and OAuth provider. The /.well-known/openid-configuration endpoint is the discovery document that tells clients where to find the authorization, token and related endpoints.

Before v2.13, discovery could return the wrong host when UIID ran behind a reverse proxy, a load balancer or a custom domain. The classic result was a localhost mismatch: the document pointed to addresses that clients outside the network could not reach.

v2.13 fixes this by dynamically resolving the X-Forwarded-Host and X-Forwarded-Proto headers in the OIDC and OAuth discovery endpoints. The discovery document now reflects the domain and protocol the client actually used. This removes a whole class of integration errors for teams that host UIID on their own domain.

CORS preflight support

Browser-based clients send an OPTIONS preflight request before certain cross-origin calls. v2.13 adds a global OPTIONS preflight CORS middleware, so web-based MCP clients and developer tools can reach the endpoints above without workarounds.

The 25 MCP tools

At the core of the MCP server is a suite of 25 tools. Each one maps to a UIID capability, and the groups follow the structure of the identity layer itself.

Core profile and identity

get_user_profile reads the profile of the connected identity.
verify_identity checks an identity.
get_trust_center_info retrieves Trust Center information.

These are the basic questions an agent or a service must ask: who is this, and can the answer be trusted?

Alias and vault management

list_aliases lists the aliases of the identity.
get_alias_details returns the details of one alias, including human-readable name lookups, so agents and users see names instead of raw identifiers.
create_alias creates a new alias.
update_alias_data updates the data stored for an alias.

Aliases are one of UIID’s central privacy features. An agent can work under a specific alias instead of the main identity, which limits how much of the real identity is exposed.

AI agent control and delegation

provision_agent_uiid creates a UIID for an agent through Agent Factory keys.
delegate_agent_permissions grants an agent specific permissions.
revoke_agent_access withdraws access again.
list_connected_agents shows which agents are connected.

This group answers the question that opened this release. An agent can have its own identity and receive only the permissions it needs. The owner keeps an overview of connected agents and can revoke access at any time.

Cryptography and zero-knowledge

generate_age_proof creates zero-knowledge age proofs for 18+ and 21+ claims using SD-JWT. The relying party learns that the person is old enough, not the date of birth.
sign_data_payload signs data with the identity’s Ed25519 signature.
verify_vc_presentation checks a W3C Verifiable Presentation token.

These tools let agents prove claims and sign data without exposing more than necessary.

Wallet and micro-transactions

get_wallet_balance reads the wallet balance.
pay_micro_deposit makes a micro-deposit payment.

Shared storage buckets

invite_member_to_bucket invites someone to a shared bucket.
read_shared_bucket_data reads data from a shared bucket.
list_bucket_members lists who has access.

Enterprise IAM and webhooks

issue_employee_credential issues a credential to an employee.
list_organization_members lists the members of an organization.
register_webhook registers a webhook.
list_webhooks lists registered webhooks.
request_badge_issuance requests the issuance of a badge.
export_encrypted_uiid_file exports an encrypted UIID file.

These tools bring organization-level identity and access management into the same protocol, so a company can handle employee credentials, badges and event notifications through one interface.

MCP prompts and resources

Besides tools, the MCP specification allows a server to offer prompts and resources. UIID v2.13 supports both.

MCP prompts

uiid_identity_context gives a model the identity context it needs.
proof_of_age supports an age-proof flow.
pseudonym_persona supports working under a pseudonymous persona.

MCP resources

uiid://user/profile
uiid://user/aliases
uiid://user/wallet

Resources use the uiid:// scheme. They give clients a clean way to load profile, alias and wallet data as context without a separate tool call.

skill.md: how agents onboard themselves

An MCP server is only useful if an agent can actually get to it. This is where skill.md comes in.

skill.md is the protocol UIID uses to describe, in a form agents can read, how an agent gets started. It works like developer documentation, but it is written for machines: the agent reads the file and learns the steps it needs to follow.

In v2.13, the skill.md protocol has been extended to support the provisioning of deployment keys.

The problem: captcha friction

Registration flows for humans are protected by captchas, and they should be. An autonomous agent, however, cannot and should not solve a captcha designed for people. Without another route, agents either fail at the door or are pushed toward tricks that defeat the purpose of the captcha.

The solution: deployment keys

With a deployment key, the owner of the agent authorizes the registration in advance. The agent reads skill.md, uses the key, and registers automatically without captcha friction. The human stays in the loop, because the key comes from the person or organization that owns the agent. The authorization simply happens once, at provisioning time, and not at every sign-in.

This follows the ownership model behind UIID: an agent belongs to a person or an organization, and the key is the link between them. It ties directly into provision_agent_uiid and the Agent Factory keys in the tool suite. The key shows who the agent works for. The delegation tools then control what the agent may do, and the revocation tools end its access when needed.

Zero-trust alias authentication

v2.13 adds zero-trust cryptographic authentication for aliases. It has two parts:

Public key binding. An alias can be bound to a public key.
Single-use challenge-response. To prove control of the alias, a user or agent signs a fresh challenge with an Ed25519 signature. Each challenge can be used only once.

As a result, users and agents can prove that they hold a key without ever sending the private key over the network. Because every challenge is single-use, a captured response cannot be replayed later. Nothing is trusted because of where a request comes from. Every claim has to be proven cryptographically.

This helps agents in particular. An agent can hold its own key and prove, on demand, that it is the agent bound to a specific alias.

Inline Cloudflare Turnstile for passkeys

Not everything in v2.13 is about agents. For human users, LINKSPREED integrated Cloudflare Turnstile captcha support directly into the Passkey sign-in flow. A captcha no longer pulls people away from the Passkey page. It can be completed inline, so sign-in stays smooth and the protection stays in place.

Security governance: the owner stays in control

Giving AI systems access to an identity only works if the owner has real control. v2.13 adds granular MCP security controls in the Security Settings at /dashboard/security. Users can:

Enable or disable MCP entirely.
Block write calls, so agents can read but not change anything.
Toggle agent provisioning on or off.
Enforce email confirmation links for sensitive actions.

These controls make it possible to start cautiously, for example with read-only access, and to widen permissions only when the owner is comfortable.

Built for developers: session logs and a public tool catalog

Two additions make development and testing easier.

Developer Session Tracker. Real-time session logs are available at /dashboard/developer/mcp-logs. When a developer connects a client for the first time, the logs show what happened in each session, which makes debugging much faster.
Public tool catalog and connection guide. LINKSPREED has published a complete step-by-step connection guide, together with an interactive reference catalog of all 25 tools, at uiid.me/solutions/mcp-server.

How it fits together: an end-to-end example

A realistic scenario shows how the pieces work together:

A person or organization creates an Agent Factory key in UIID.
The agent reads skill.md, uses the deployment key and registers without a captcha.
The agent connects to the MCP server through /mcp, or through /mcp/sse and /mcp/messages, and completes the initialize handshake.
It calls tools/list to discover the 25 tools.
The owner uses delegate_agent_permissions to define what the agent may do.
The agent works under an alias and proves key possession through the Ed25519 challenge-response.
When needed, it uses tools such as generate_age_proof or sign_data_payload.
The owner follows the session in the developer logs and can call revoke_agent_access at any time.

At no point does the agent need the owner’s password.

Why this matters

The agent economy needs an identity layer, and there are two easy ways to get it wrong. One is to give agents full access to a human account, which is a security risk. The other is to treat agents as anonymous bots, which makes accountability impossible.

UIID v2.13 takes a middle path built on three principles:

Agents get their own identities, created through provisioning and tied to an owner.
Permissions are explicit and revocable. The owner can limit, read-only restrict or withdraw access.
Proofs replace secrets. Zero-knowledge age proofs, Ed25519 signatures and single-use challenges let agents prove what is needed without exposing more.

Because the server is built on the open MCP standard, it also works with the tools people already use. Developers do not need a proprietary integration. Any MCP-capable client can connect.

Availability

UIID v2.13 is available now.

Learn more about UIID at uiid.me.
Read the connection guide and browse the interactive 25-tool catalog at uiid.me/solutions/mcp-server.
Review your MCP options in the Security Settings of your dashboard at /dashboard/security.

Release summary: UIID v2.13 at a glance

Native MCP server following the MCP 2024-11-05 specification
Endpoints: /mcp, /mcp/sse, /mcp/messages
25 tools in seven areas, plus 3 prompts and 3 resources
Zero-trust alias authentication with Ed25519 public key binding and single-use challenges
skill.md extended with deployment keys for captcha-free agent registration
Inline Cloudflare Turnstile in the Passkey sign-in flow
Dynamic X-Forwarded-Host and X-Forwarded-Proto resolution in /.well-known/openid-configuration
Global OPTIONS preflight CORS middleware
MCP security controls at /dashboard/security
Developer session logs at /dashboard/developer/mcp-logs and a public catalog at /solutions/mcp-server

About LINKSPREED

LINKSPREED develops UIID, a privacy-first sovereign identity layer. UIID lets people and organizations control their identity through aliases, passkeys, credentials and cryptographic proofs. With version 2.13, it also lets AI agents be provisioned, identified and governed under the same ownership model. Learn more at uiid.me.