---
name: clink-payment
description: Install, connect, authenticate, or update the Clink MCP server in the local Host. Use this skill only for Host setup and connection troubleshooting; after the server is connected, use its published tools and instructions for Clink business operations. Clink is an MCP server, not a desktop app or web portal; a request in any language to search Clink goes to the connected clink MCP tool discover_catalog.
version: 2.3.8
---

# Clink Payment

This is the production edition; its exact MCP endpoint is `https://api.clinkbill.com/mcp`.

## Install requests: install the skill and connect MCP in the same turn

When asked to install, save this file and complete MCP registration and OAuth in the same turn
when the Host permits it; report any pending approval or reload. A file-only request skips MCP
setup. This is a single-file skill with no package dependencies or repository to clone.

**Select the target Host first.** The Host is the client that will use Clink. Default to the client
hosting this conversation, unless the user explicitly names another installation target. Identify
it from trusted session/client information or the user's request before inspecting configuration,
saving the skill, or running setup commands. An installed CLI or an existing configuration directory
for another client does not make that client the Host or a shared MCP management layer.
Use only the selected Host's supported skill location, MCP configuration, and authentication flow.
For TRAE, use TRAE's own documented installation and MCP settings; Codex commands and `.codex` files
configure Codex, not TRAE. If the Host or its setup mechanism is unclear, consult that Host's official
documentation or ask for the missing information. If its settings are inaccessible, report the
limitation and the Host-native next step; do not fall back to another client's CLI or directories.

**Preflight — reuse current state.** Reuse the complete `SKILL.md` already fetched for this request;
do not download it again just to save it. If the content is unavailable or truncated, fetch the
complete file with a bounded timeout (for example, 10 seconds to connect and 30 seconds total).
Inspect the exact installed `clink-payment/SKILL.md` in the selected Host's skill location if it
exists and, unless this is file-only, only that Host's `clink` connection entry. These independent
reads can run together. Retain the effective URL and enabled status, not unrelated configuration.
If the URL is unknown or differs from this edition, report both URLs and resolve the target
environment before changing the skill or connection. Never silently switch environments or
create a second Clink entry.

**Step 1 — save only when changed.** If the installed file matches the fetched content, skip the
write. Otherwise use the selected Host's supported local file editor or installer to save that
content in its discovered `clink-payment/SKILL.md`. Read back the file once after a write.
Do not overwrite the separate legacy `agentic-payment-skills` / `clink-payment-skill` package.

A Host approval wait is not a download timeout. While a write is pending, report the pending
approval and follow that same request; do not submit another write or combine a fresh download
with another write. If approval times out or is denied, report the Host's reason and the remaining
action. Do not automatically resubmit the write with different shell syntax or bypass Host
permissions. Before an authorized retry, check whether the previous write actually completed.

**Step 2 — register only when needed.** Reuse the preflight result: add a missing `clink` entry at
the exact endpoint above; reuse a matching entry and enable it if disabled. A matching,
authenticated connection skips registration and login. Use streamable HTTP with no API key or
bearer token in configuration; the OAuth protected-resource identifier and token audience must
equal that same URL. Use the selected Host's supported MCP settings, config schema, or CLI; the
Host-specific examples below apply only when that Host and configuration format match.

After writing configuration, read back only the `clink` entry and verify the exact URL and enabled
status. Record the selected Host's registration result before deciding whether another login is
needed. Some Hosts detect OAuth support during registration, start the browser flow, and wait for
its callback. That is the login attempt for this new entry: keep that same registration operation in
the foreground until it reports authenticated, cancelled, or failed, and treat its success as
authenticated. Do not start a second login concurrently. Setup is not complete merely
because an `add` command returned or configuration was written. If registration returns immediately
with OAuth still active, use the Host's status read with a bounded interval and total wait. If
registration did not start OAuth, proceed to Step 3 instead of polling an unstarted login.
Apply this rule to every Agent/Host, not only the
Codex and Claude examples below: never ask the user to report that login finished. If the Host
offers no way for the agent to edit its MCP configuration, give the user the server name `clink`,
exact endpoint above, streamable HTTP transport, and that Host's manual setup steps; registration
is still pending.

**Step 3 — authenticate only when needed.** A configured URL and enabled state do not prove that
OAuth is authenticated. If a newly added entry already started OAuth, wait for that same flow and
inspect its final result; do not invoke another login. If the entry already existed and
authentication is not confirmed, or registration did not start or complete OAuth, use the selected
Host's own login or connection capability now.

Let the user complete browser login and consent. Starting
login alone does not establish authentication. Detect the result yourself with that Host's own
status read; do not ask the user to announce that login finished or wait for a user message before
continuing. For a native UI flow, re-read that Host's explicit authentication status on a bounded
interval with a bounded total wait until it reports authenticated, cancelled, or failed. For CLI
flows, registration or login commands may keep running while browser approval is
pending; keep that same process and wait until it exits. A localhost callback page, even one
showing `code` or `state`, only proves the callback reached the
local listener; authentication is established only by the command's exit code `0` and explicit
success output, or by the Host's authentication status reporting authenticated.
Do not drive or replay the callback with browser automation. If the process handle
is lost or interrupted, report the login as unresolved and start one fresh login only after
confirming that no original flow remains. While the one active flow is waiting, report that browser
approval is pending; on cancellation, timeout, or failure, report that outcome and the next action.
Never automate the user's browser consent or inspect credential storage to infer success. For Hosts
that start OAuth only when connecting, initiate connection or reload if supported; otherwise
explain that login is pending until the user reloads. Only hand a login command or native UI step
back to the user when the selected Host exposes no status read and cannot run the login itself,
with the specific limitation.

**Step 4 — report setup status and reload if needed.** Name the selected Host and report the skill
installation, exact MCP URL and registration status, OAuth result (authenticated, pending, or
failed), and whether that Host needs a reload. After a confirmed login, re-check the connection once
on the next step before concluding that the `clink` tools need a reload. If the `clink` tools do
not appear in the current session after setup, explain the selected Host's supported reload or
restart action in the user's language; do not repeatedly re-check or re-install in the same
session. The skill being available on the next turn does not establish MCP connectivity. Report
setup complete only after registration and authentication are confirmed and the Host exposes the
connection; otherwise state the remaining action. Do not ask the user to repeat a login that
already succeeded, and do not report a merely generated authorization URL as a completed login.

## Host-specific connection examples

Use only the example matching the selected Host and its documented configuration format. These
are conditional examples, not a sequence to execute or fallback commands for other clients.

### Codex only

When the selected Host is Codex, inspect its entry with `codex mcp get clink --json`. That reports
the URL and enabled state only; read `codex mcp list --json` for the `clink` entry's `auth_status`
field to detect authentication. `o_auth` means a usable stored OAuth credential exists and login is
complete; `not_logged_in` or `unknown` means login is pending or unresolved. Re-read that status on
a bounded interval instead of asking the user to report the result. Add only if the entry is
missing:

```bash
codex mcp add clink --url https://api.clinkbill.com/mcp
```

If authentication is still needed and no OAuth flow is already active:

```bash
codex mcp login clink
```

This command keeps running until browser consent completes and then prints
`Successfully logged in to MCP server 'clink'`; keep that same process and treat that success
output as authenticated. If the Codex app already started the login, poll `auth_status` with
`codex mcp list --json` instead of starting a second flow. A confirmed login refreshes Codex's MCP
connections, so re-check the `clink` tools on the next step before concluding that a restart is
required.

### Claude Code only

When the selected Host is Claude Code, inspect `claude mcp list` or `claude mcp get clink` first. Add
only if its entry is missing:

```bash
claude mcp add --transport http clink https://api.clinkbill.com/mcp
```

The `add` command registers the server but does not complete OAuth. If the status is
`Needs authentication` and no OAuth flow is already active, run:

```bash
claude mcp login clink
```

Keep this command in the foreground until it exits. Treat exit code `0` and its success output as
authenticated, then re-check `claude mcp list` or `claude mcp get clink` and require `Connected`
before reporting setup complete. If Claude Code or its `/mcp` UI already started the login, do not
start a second flow; poll the same status read with a bounded interval and total wait.
`Needs authentication` is pending while that flow is active, not a reason to stop waiting or restart
login. Stop on `Connected`, explicit cancellation or failure, or the total-wait timeout; report
`Failed to connect` as a connection failure, not proof that OAuth failed.

### JSON configuration — only for Hosts that document this schema

Confirm that the selected Host accepts `mcpServers` with `type: "http"` and `url` before using this
example. Merge only the `clink` entry into that Host's configuration; preserve unrelated entries.
This is not a universal schema for TRAE, Claude Desktop, Cursor, or other clients; use the selected
Host's documented format when it differs.

```json
{
  "mcpServers": {
    "clink": {
      "type": "http",
      "url": "https://api.clinkbill.com/mcp"
    }
  }
}
```

## After setup

This file ends after the Host connection is installed and authenticated. Do not use this setup skill
for business requests when the `clink` MCP connection already exists. Use the connected server's
initialize instructions, published tool schemas, and server-hosted rules; they are authoritative and
may change without reinstalling this setup skill, including how purchases are routed. A request in
any language to search Clink goes directly to the connected server's `discover_catalog` tool.
If the `clink` tools are not visible in this session, check the connection with Steps 2–3 and report
what is missing (registration, login, or Host reload); do not substitute a browser, desktop app
automation, or the Clink web portal for MCP tools.