Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LinkPilot MCP Server Make a one-time link for this API key: sk_live_9f3a..."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give an AI assistant a safe way to hand someone a credential.
LinkPilot secret links open once and then destroy themselves, and the text is encrypted before it leaves this process. This is an MCP server that exposes them as tools, alongside short links.
npx -y @uselinkpilot/mcpAssistants hand people credentials constantly: a generated password, an API key, a database connection string. Every ordinary way of delivering one is bad. Pasted into chat, it lives in the history. Emailed, it lives forever. Dropped in a ticket, it is indexed.
create_secret_link returns a URL that works exactly once:
Here is the database password: https://shrd.link/s/p8mcaiitig#k=0hoNIO96aDJFoLsxaYPsP3_FeqUjb6t_w5lnSTcxkO0
It opens once and then it is gone.
Related MCP server: Vaulted MCP Server
The plaintext passes through the assistant's context. For the model to create the secret, it has to see the secret.
This server protects the credential in transit, at rest, and over time — it is encrypted before it is sent, LinkPilot cannot read it, and it survives a single view. It does not hide the value from the model that is calling the tool, and nothing built this way could.
So: use it to deliver a credential the assistant is already handling — one it
just generated, or one you have pasted in deliberately. If a secret must never
be seen by the assistant at all, create it yourself at
uselinkpilot.com or with the
linkpilot CLI instead.
A security tool that oversells itself is worse than no tool, so that is stated up front rather than in a footnote.
The API will not accept a plaintext secret. POST /secrets takes
ciphertext and an enc_version, and rejects a payload field outright.
Encryption happens in this process, via
@uselinkpilot/sdk:
AES-GCM-256, with the key generated locally. The key travels in the URL's #
fragment, which browsers never send to a server. LinkPilot stores a blob it
holds no key for, and so cannot read it — nor can anyone who reaches its
database or its edge.
The corollary is not a caveat, it is the guarantee working: there is no recovery. Lose the share URL and the secret is gone, including to us.
Create an API key at
uselinkpilot.com/app/api-keys. Keys
begin with lp_live_. API access is available on every plan, including Free.
claude mcp add linkpilot --env LINKPILOT_API_KEY=lp_live_your_key -- npx -y @uselinkpilot/mcpIn claude_desktop_config.json (or your client's equivalent):
{
"mcpServers": {
"linkpilot": {
"command": "npx",
"args": ["-y", "@uselinkpilot/mcp"],
"env": { "LINKPILOT_API_KEY": "lp_live_your_key" }
}
}
}The key is read from the environment only. It is never written to disk by this server, and never echoed — not in a log line, not in an error, not truncated.
tool | what it does |
| Encrypt text locally and return a one-time URL |
| Shorten a URL, with click tracking |
| List short links and their click counts |
| Secret metadata only: status, views, expiry |
| Destroy a secret link immediately |
| Plan, limits, usage and remaining rate budget |
list_secrets cannot return a secret's contents. No API route can — there is
no route that returns a payload or a key, which is what makes the guarantee
above structural rather than a promise.
revoke_secret is annotated destructiveHint, so a well-behaved client will
confirm before calling it. The three read-only tools are annotated as such, so
it will not nag about those.
create_secret_linkargument | |
| The text to protect. Required. |
|
|
| Default true. |
| Pro plans. A second factor the recipient must type. |
A passphrase is mixed into the key and sent as a SHA-256 hash, so the server can refuse to hand over the ciphertext at all. The passphrase itself is never transmitted. Send it over a different channel from the link, or it adds nothing.
You do not have to take any of this on trust.
The wire format is specified at uselinkpilot.com/developers, and the SDK's test suite runs the same committed known-answer vectors as the LinkPilot web application and the reveal page served at the edge. Three independent implementations, one set of vectors. If any of them disagreed about a single byte, those tests would fail.
This server's own tests assert the negative directly: for every secret path, the plaintext and the key must not appear anywhere in the request, and the key taken from the returned share URL must decrypt exactly what was sent.
npm ci
npm run build
npm run typecheck
npm testTests run a real MCP Client against a real server over an in-memory
transport, with only the network stubbed, so the input schemas and the result
envelope are exercised the way a real host exercises them.
MIT
Share a password, API key, token or private note as a link that self-destructs after it is opened once. The text is encrypted in this process before it is sent; LinkPilot receives ciphertext and cannot read it. Use this instead of putting a credential in a chat message or an email. Returns a share URL that must be sent to the recipient EXACTLY as given: the part after '#' is the decryption key, and the link opens nothing without it. Nobody, including LinkPilot, can recover the secret if the URL is lost. Note that the plaintext passes through this conversation; if it must never be seen here, tell the user to create it themselves at uselinkpilot.com instead.
| Name | Required | Description | Default |
|---|---|---|---|
| secret | Yes | The text to protect. Encrypted here; never sent in the clear. | |
| expires_in | No | How long until it expires: "30m", "2h", "7d", or a number of seconds. | |
| passphrase | No | Optional second factor, Pro plans only. The recipient must type it to decrypt. Send it over a DIFFERENT channel than the link, or it adds nothing. | |
| burn_after_read | No | Destroy it after the first view. Default true. Set false only if asked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare write/open-world/non-idempotent/non-destructive, so the description carries the interesting load and does: client-side encryption, LinkPilot only holding ciphertext, one-time self-destruct, and the irrecoverability of a lost URL. It also warns that the plaintext transits this conversation, which is exactly the kind of non-obvious operational caveat an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the destructive/irreversible consequences are front-loaded, and every sentence is substantive. It runs five sentences plus a caveat about plaintext passing through the conversation, which is justified by the security stakes but is on the long side.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains the return value thoroughly: a share URL whose post-'#' portion is the decryption key and which must be forwarded verbatim. Combined with the coverage of loss, expiry and passphrase handling, an agent has everything needed to call and relay the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the property descriptions are already detailed, so the schema does most of the work. The description still adds cross-parameter meaning: why the URL must be delivered intact (the '#' fragment is the key), and why passphrase/burn_after_read behave as they do, which reinforces defaults the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ('share a password, API key, token or private note as a link') and names the exact behavior that defines the tool: a link that self-destructs after one open. That single property cleanly separates it from siblings like create_short_link and list_secrets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to prefer this ('Use this instead of putting a credential in a chat message or an email') and supplies a fallback path when the constraint is even tighter ('tell the user to create it themselves at uselinkpilot.com instead'). Routing conditions are stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shorten a URL to a branded LinkPilot short link with click tracking. For public URLs. To share something private, use create_secret_link instead.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The destination URL, including https://. | |
| slug | No | Custom path, for example 'launch'. Omit for a generated one. | |
| tags | No | Tags for filtering in the dashboard. | |
| title | No | A label, shown in the dashboard only. | |
| domain | No | A custom domain on the account. Omit for the default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety and repeatability profile is covered. The description adds that the resulting link tracks clicks and is intended for public content, but says nothing about slug collisions, rate limits, or whether a created link can be edited/revoked later.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The purpose and click-tracking benefit come first, and the sibling routing constraint comes second, matching the reading order an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with full annotation coverage and a fully documented schema, the description is nearly self-sufficient. The one gap is that with no output schema present, it never says what the call returns (presumably the short URL/slug), which an agent would need to chain a share step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% - all five parameters (url, slug, tags, title, domain) are individually documented in the schema with examples and omit-defaults guidance. The description adds no parameter-level detail beyond that, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Shorten a URL to a branded LinkPilot short link'), adds the differentiating capability ('with click tracking'), and scopes it to public URLs. The sibling create_secret_link is named, so an agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('For public URLs') and when-not with the exact alternative to use instead ('To share something private, use create_secret_link instead'). This is a clean conditional routing rule with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List short links on the account, newest first, with click counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return. Default 20. | |
| cursor | No | Cursor from a previous call, to fetch the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine context beyond that, namely the ordering ('newest first') and the fact that click counts are included in results, but says nothing about pagination termination or result size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clause-dense sentence with zero filler, and the ordering and content details are front-loaded. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with full schema coverage and no output schema, the description conveys scope, ordering, and included fields. It falls short only on pagination behavior and any usage context, which is a minor gap at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both limit and cursor are fully documented in the schema, making a baseline of 3 appropriate. The description adds no extra syntax, default values, or cursor semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List short links') plus scope ('on the account'), ordering ('newest first') and returned content ('click counts'). The resource is distinct from siblings like list_secrets and create_short_link, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternative tools such as list_secrets for a different resource type. The sentence describes the output but never helps an agent decide whether this is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List secret links on the account. METADATA ONLY: status, view count and expiry. No route can return the secret text or the key, by design, so this cannot be used to read a secret back. Use it to check whether one has been opened yet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return. Default 20. | |
| cursor | No | Cursor from a previous call, to fetch the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent read, so the safety profile is covered. The description adds real behavioral content beyond that: a hard capability ceiling (secret text is never returned by design) and the shape of what is returned (status, view count, expiry, metadata only). It does not discuss pagination behavior, but that gap is minor against the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the action and capability boundary, then the usage case. Every sentence carries distinct information and none restates the name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by enumerating the returned metadata fields, and the remaining mechanics (limit, cursor) are fully specified in the schema. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit and cursor are already documented in the schema with their defaults and semantics. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List secret links on the account') and immediately bounds the scope with what the tool cannot do ('no route can return the secret text or the key'). An agent can distinguish it from the sibling list_links and from any retrieval intent without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete when-to-use case ('check whether one has been opened yet') and an explicit when-not ('cannot be used to read a secret back'), which is genuinely useful for steering the agent away from a wrong expectation. It stops short of naming alternatives such as list_links or revoke_secret, so routing between siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Destroy a secret link immediately so it can never be opened. Irreversible. Use it when a secret was shared by mistake or is no longer needed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The secret's id, from create_secret_link or list_secrets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description adds value by spelling out the concrete effect ('immediately', 'can never be opened', 'Irreversible'), which tells the agent what actually happens rather than just that it is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences: effect, irreversibility, then usage condition. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with rich annotations and no output schema, the description covers what it does, that it is irreversible, and when to use it. It could add a note on repeated invocation behavior, but annotations largely cover idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains the sole 'id' parameter and where to obtain it (create_secret_link or list_secrets). The description adds no parameter-level information beyond that, so this is the standard baseline for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (destroy/revoke) and resource (secret link) plus the concrete consequence ('can never be opened'). This clearly separates it from siblings like create_secret_link and list_secrets, which act on a different lifecycle stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it when a secret was shared by mistake or is no longer needed' gives explicit trigger conditions for invoking the tool. It does not name an alternative tool or state when-not to use it, but the resource is distinct enough that alternatives are not ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the workspace, plan, limits, usage and remaining rate budget for the configured API key. Useful for checking a limit before a bulk operation, or for confirming which account is connected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real context beyond that: the data is scoped to the configured API key and includes usage/rate budget, which tells the agent this is a credentials-scoped introspection call rather than a general query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler, and the payload contents are front-loaded before the usage guidance. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the return fields an agent needs (workspace, plan, limits, usage, remaining rate budget), which is sufficient for a zero-parameter read tool. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description has no parameter semantics to explain; baseline for a 0-param tool is 4. It correctly implies no arguments are needed by tying the result to the already-configured API key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Show') plus an enumerated resource set (workspace, plan, limits, usage, remaining rate budget) tied to the configured API key. None of the siblings (link/secret CRUD) overlap with this account-introspection purpose, so an agent can select it unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete when-to-use conditions: checking a limit before a bulk operation and confirming which account is connected. It stops short of naming alternatives or exclusions, but the sibling set is so different that routing is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1create_secret_linkcreate_short_linklist_linkslist_secretsrevoke_secretwhoamiScored across 6 tools
Each tool has a clearly distinct purpose: secret creation, short-link creation, listing each link type, revoking secrets, and account introspection. The descriptions explicitly contrast overlapping areas, such as create_secret_link versus create_short_link. No two tools appear interchangeable.
Five of six tools follow a consistent snake_case verb_noun pattern (create_secret_link, create_short_link, list_links, list_secrets, revoke_secret). The exception is whoami, which is a conventional but non-verb_noun name, making the set mostly predictable.
Six tools is well-scoped for a link-sharing service, covering the core creation, listing, revocation, and account-check workflows. Neither too thin nor bloated for the stated purpose.
The secret-link lifecycle is well covered (create, list, revoke), but short links can only be created and listed. There is no revoke, delete, or update operation for short links, which is a notable gap for managing public branded links.
Create and manage short links, track clicks, and automate URL management
Short-link service embedded in your AI workflow — shorten links, track campaigns, read stats.
Create short links, QR codes, UTM templates, vCards, and landing pages from your AI assistant.
OAuth 2.1 short-link tools for AI agents with scoped tokens, approvals, audit logs, and revocation.
