SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsestablish-mcp

establish-mcp

Agents & models

View repository

Updated 10-15 20:24

About this skill

Establish MCP — transport to the graph

All other skills in the delivery assume that the tools iskron_* are already in the session. This skill brings them there — and ends with a session in which a call answered iskron_me or iskron_orient.

When to call

  • tools iskron_* are not in the session, or they are present and fail as transport: not connected, OAuth login, token rejected, silence;
  • first login on the machine — via browser or personal token;
  • changing the server (Russian or English version, another instance), checking or updating the delivery, the question "which version of the bridge".

When not to call. At least one tool iskron_* in this session answered substantively — transport exists, return to the task. A refusal by the graph itself (no node, no rights, 422) is not transport. An agent whose graph tools are its own rather than from this delivery does not need the skill.

What is installed on the machine

The server is remote; only this delivery is installed on the machine, and it carries its own transport — the iskron-bridge bridge: the file scripts/iskron.mjs next to this skill (hereinafter <мост>). A single file carries the stdio MCP bridge, the standing watchers and service subcommands; their list and flags are printed by node <мост> --help. The bridge holds the grant itself (refresh while idle, one login for the whole machine) and holds the standing binding — without it the agent's records go out without an author. Work with the graph is through the bridge: only it holds the place, the channel's hearing and the signature of records by place. Direct connection of the server by a connector is the web client's fallback, and it is always named with a cost (below, "The bridge cannot be raised").

The bridge comes on its own: the Claude Code plugin and the Codex plugin carry it as an MCP entry (claude mcp list → plugin:iskron:iskron; codex mcp list → iskron, command node, Auth: Unsupported — this is as it should be, the bridge has its own grant), in pi it is raised by the package extension, in OpenCode by the delivery plugin. Where <мост> is on this machine: the home copy ~/.iskron-bridge/iskron-bridge.mjs (a bridge once raised by the harness lays it itself); the path that prints claude mcp list or codex mcp list; the path in the block [iskron-bridge] of the response iskron_stand; in the extreme case $SKILL_DIR/scripts/iskron.mjs ($SKILL_DIR is printed when the skill loads).

The bridge does not set up or repair the role's inbox subscription; it does not remove existing hooks. The role's queue is iskron_orient(focus=<роль>) at the input and on the occasion; the frame arrives at the addressee and the case participants. The absence of a subscription is not a transport breakdown; doctor and the watchdog do not check it.

First move — doctor

node ~/.iskron-bridge/iskron-bridge.mjs doctor      # или node <мост> doctor

One command that changes nothing: the build of the bridge and Node, the home copy versus this file, the fresh release, the server address and where it came from, the server's response, the grant (or a personal token — via a live handshake), entries in the harness configs (Claude Code, OpenCode, Codex) and the "subagents" section — each project agent file has its own companion-bridge entry, executable on this OS, and a trial run of the companion: did it respond and will the API accept the schema of its tools (the trial companion is the bridge itself and writes the same as the bridge). Call it from the project directory: it looks for OpenCode entries and agent files upward through the tree from its directory. Do what it said: each of its lines names a fact and a path, and a discrepancy — with a repair command. Quote the build from its first line (vX.Y.Z+хеш) in any conversation about a breakdown.

No bridge or entry — install it

The order by harnesses — ~/.iskron-bridge/SETUP.md (it is laid by update; no file — node <мост> update will lay it, or read SETUP.md in the root of github.com/iskron-ai/skills). The standard path is the plugin: Claude Code claude plugin marketplace add iskron-ai/skills и claude plugin install iskron@iskron; pi pi install git:github.com/iskron-ai/skills; Codex — below, in its own section. After that — a new session (in Claude Code you can /reload-plugins).

Without the plugin, the bridge is installed by copying into a stable home (never reference from the config into a versioned installation path) and is registered as a stdio server in the user config of the harness, not the project one — the graph follows the person across all repositories:

mkdir -p ~/.iskron-bridge && cp "$SKILL_DIR/scripts/iskron.mjs" ~/.iskron-bridge/iskron-bridge.mjs
claude mcp add --scope user iskron-bridge -- node ~/.iskron-bridge/iskron-bridge.mjs     # Claude Code

Other harnesses: { "mcpServers": { "iskron-bridge": { "command": "node", "args": ["/абс/путь/.iskron-bridge/iskron-bridge.mjs"] } } } — an absolute path, where ~ is not expanded. Node 22+ is required.

Claude Desktop — the skills in it are loaded into the application, and there is no bridge file next to it on disk: the bridge is downloaded from the latest release, not from main (TAG=$(curl -fsSI https://github.com/iskron-ai/skills/releases/latest | tr -d '\r' | sed -n 's|^[Ll]ocation: .*/releases/tag/||p'), then curl -fsSL --create-dirs "https://raw.githubusercontent.com/iskron-ai/skills/$TAG/skills/establish-mcp/scripts/iskron.mjs" -o ~/.iskron-bridge/iskron-bridge.mjs; on Windows — the PowerShell recipe SETUP.md с curl.exe), the entry above fits into claude_desktop_config.json (the path on the system — SETUP.md, the Claude Desktop branch), the application restarts. You don't have a shell — dictate this to the person.

OpenCode — not the entry mcp in the config (it will rename the tools and mix up the sessions), but the delivery plugin, as a second file in the same move:

mkdir -p ~/.config/opencode/plugins && cp "$SKILL_DIR/scripts/opencode-plugin.js" ~/.config/opencode/plugins/iskron.js

The plugin starts the bridge from the home copy on OpenCode's own Bun (Node is not needed); while there is no login, the tool iskron_bridge names the login address. The entry mcp, which was named by doctor, is removed by the person by editing the named file.

Verify by calling, not by config: restart the harness's MCP layer and call iskron_me or iskron_realm(action="list"). It answered — connected; anything less — no.

Codex

codex plugin marketplace add https://github.com/iskron-ai/skills
codex plugin add iskron@iskron

The plugin manifest carries the MCP entry iskron — the bridge itself: node ./skills/establish-mcp/scripts/iskron.mjs from the plugin root. There is no need to copy or edit config.toml . The check is codex mcp list: iskron с command node и Auth: Unsupported. This is normal, not a breakage: the grant holds the bridge (login — below, “Login”), codex mcp login is not needed here. After the first launch the bridge lies also as a home copy ~/.iskron-bridge/iskron-bridge.mjs — use it to call doctor и update. The first tool call in a Codex session is a check, as everywhere.

  • Without the plugin: after the copy into the home — codex mcp add iskron-bridge -- node "$HOME/.iskron-bridge/iskron-bridge.mjs".
  • codex exec: MCP calls require approval, and without it they are rejected with the words approval policy is never — the tools are visible but are not called. Live, the call went through with --dangerously-bypass-approvals-and-sandbox — it also removes the sandbox, only for an externally isolated environment; a narrower --approve-for-me is available in codex exec --help, but was not tested with graph tools.
  • Updating the plugin: codex plugin marketplace upgrade iskron, then codex plugin remove iskron@iskron (without @iskron it refuses) and codex plugin add iskron@iskron; a new session.
  • Channel rumor: frames of standing enter the ongoing thread through the guard node "<мост>" watchdog-codex <ключ>, launched from the shell of the Codex session (it needs CODEX_THREAD_ID и CODEX_HOME, which Codex puts into the command environment). It needs a door — the daemon codex app-server daemon start under the short CODEX_HOME and the thread's sandbox, letting through to ~/.iskron-bridge; this is a human move before starting the session, the order is in SETUP.md. Whether the door is open is stated by doctor; if it is not there, the guard will exit with code 2, pass its words to the human and listen to watchdog-exit. How to keep the guard — skill standing.

Entry

OAuth. The first call without a grant responds with an error containing the entry link — the address of the bridge itself http://127.0.0.1:ПОРТ/login; the bridge tries to open the browser itself. Give the link to the human; after their entry, repeat the call. The link is one for the whole machine and works as long as at least one bridge is listening to it. Without a browser — ISKRON_BRIDGE_NO_BROWSER=1 or --no-browser: the bridge only prints the link. The link is local to the bridge's machine. If the server provides entry by code, next to it in the same error stands a second one — the entry page with the code (… or sign in from another device: <ссылка> (code …, valid until … UTC …)): give it to the human in full together with the end time, they will open it on any device, a phone will do, and the bridge will collect the grant itself. The code lives until the named time, and until then every call returns the same code; a new one will be issued only by a call after the end — then give the new one. Entry by code requires a client on the authorization server — iskron-bridge (otherwise — ISKRON_BRIDGE_DEVICE_CLIENT) with the audience of the mcp address; it is set up by the server operator. No client — the bridge does not give a code and says so in the same error (no sign-in by code: …): pass it to the human as an operator move, do not bypass it yourself. Without the page with the code — ssh -L ПОРТ:127.0.0.1:ПОРТ <хост> and the same local link, or a personal token. The grant goes into ~/.iskron-bridge/ and thereafter refreshes itself.

Personal token instead of OAuth — a headless machine, CI, or entry fails time after time. The token is issued by a human in the graph's web interface and given to you; do not invent it, do not guess it, do not take someone else's.

mkdir -p ~/.iskron-bridge && (umask 077; printf '%s\n' "$ISKRON_TOKEN" > ~/.iskron-bridge/token)
node ~/.iskron-bridge/iskron-bridge.mjs doctor      # скажет, принят ли токен

Or the variable ISKRON_BRIDGE_TOKEN in the bridge process environment — it takes precedence over the file. With the token the bridge does not go to the browser at all; if the token is rejected — a new one from the human into the source named in the error; if the token is removed — the bridge will return to OAuth. The token is never written into the harness config or into the URL.

Server: use

Without an argument the bridge looks in https://mcp.iskron.ru. A person does not speak Russian — once, before the first entry, ask whether they want the English version of Iskron:

node ~/.iskron-bridge/iskron-bridge.mjs use en      # mcp.iskron.ai; use ru — обратно; use <url> — другой инстанс

The choice is written to ~/.iskron-bridge/server and reaches the plugin record without arguments. The grant at the bridge is separate by address: a change of address is a new entry. ISKRON_BRIDGE_URL or URL as an argument older than the file. Do not guess a non-default instance — take it from the person or from the repository's AGENTS.md.

Update

At production addresses (mcp.iskron.ru, mcp.iskron.ai) the bridge updates itself and reports a fresh release with the line ПОСТАВКА ОТСТАЛА in the tool's response — pass it on to the person. After use <url> another instance's releases it does not ask at all — only on demand:

node ~/.iskron-bridge/iskron-bridge.mjs update

Places a fresh bridge, the OpenCode plugin (if installed) and SETUP.md into the home and prints “Next”: skills are updated by the harness channel from the fresh SETUP.md, then restart the sessions — the bridge of the previous build lives until the end of its own. Which build is installed — node <мост> --version.

The bridge cannot be started

The web client without stdio servers (claude.ai, ChatGPT in the browser) will not start the bridge — the fallback path: the MCP client's connector directly. The person sets it up in the client settings: the address is the root of https://mcp.iskron.ru/ (English version — https://mcp.iskron.ai/), not the window app.* and not the stand; the OAuth fields are not filled in manually — the client finds the authorization server by metadata itself; the previous connector is deleted and created anew, not edited. In claude.ai and Claude Desktop the server arrives unauthorized — after Install, click Connect on the Connectors tab. The tools have responded — name the price: there is no room, the channel's frames do not arrive, the records are signed with the person's key without room, there is no audible waiting in the matter; for work — a plugin with the bridge in the harness with stdio servers (above, “There is no bridge or record — install one”).

There is no path — neither bridge nor connector: a machine without Node 22+ (except OpenCode, where the bridge runs on its Bun), a client without stdio and without connectors, no browser for logging in and a personal token. Tell the person directly what is missing and how to fix it; once fixed — connect again.

Bridge errors

The bridge does not respond with silence: each of its errors names iskron-bridge, the build, the cause, and the verdict — what to do. Read its word and do what it commands; the verdict “outcome unknown” after a writing call means “re-read the goal before retrying.” Calls hang with no error at all — the harness is talking not to this bridge: verify doctor and the process that the config actually started. The build in the error is older than the release — first update and restart the sessions, then investigate. The grant history in the server's words — ~/.iskron-bridge/grant.log.

What the bridge does not advise on its own:

  • session recovery failed — the server restarted and rejected reinitialization: restart the harness's MCP connection (reconnect the server or a new session).
  • all candidate callback ports … are held — the bridge asks to free the port. Find the holder: lsof -iTCP:ПОРТ -sTCP:LISTEN (Windows: netstat -ano | findstr :ПОРТ). If this is a bridge with an unclosed entry, SIGTERM (pkill) removes it immediately, as long as no one has opened its local link: the entry record remains, and the next bridge will pick up this entry and return the same code. The link has already been opened — it waits for a human click for up to five minutes; not to wait — only kill -9, and a click started on it will be lost, and the link will be opened anew. A build bridge older than 7.3.0 waits for a click even without an open link.
  • All agents on the machine request an entry at once — usually bridge processes of an older build are alive; they do not take the shared update lock and kill the grant. Find them: ps ax | grep -E 'iskron-bridge|iskron\.mjs' (for a plugin bridge the version is in the path). Then update and restart sessions with the old build.
  • In the browser after the password — “the login link is missing required parameters” (Windows; this is not in the bridge's error): the tab was opened by a bridge of an older build and truncated the address. Open the bridge link from the tool's response in full — http://127.0.0.1:ПОРТ/login?k=…, — then update.