Runstack — Everything It Offers

The tool layer for AI agents — discover tools on demand, connect accounts only when needed, and execute through a secure layer where tokens never reach the model.

Source: https://runstack.engineer/blog/introducing-runstack

Runstack is the meta tool layer for AI agents. It lets any LLM use hundreds (and, by design, thousands) of real-world apps and tools without loading their definitions into the context window. Agents discover tools on demand, connect accounts only when needed, and execute through a secure layer where tokens never reach the model.

• Hosted app: runstack.engineer
• Hosted server: app.runstack.engineer
• MCP endpoint: app.runstack.engineer/mcp clients use POST
• Documentation: runstack.engineer/docs
• OSS toolkit registry github: deepraj21/rnsk-toolkits & package at @rnsk/toolkits

<BlogSectionImage caption="https://runstack.engineer landing page" />

The problem Runstack solves: context bloat

Every tool you hand an LLM costs context: its name, its description and its full JSON schema go out on every request. Connect a few apps and the model is reading thousands of tokens of tool definitions before it has even read the user's message. As the tool count grows:

• Cost goes up. Input tokens scale with the number of tools, not with the task.
• Latency goes up. Bigger prompts are slower prompts.
• Hard limits appear. Providers cap the number of tools per request, and context windows fill up.
• Accuracy goes down. With 200 similar tools in view, the model picks the wrong one more often.

The usual workaround is to hand-pick a small tool list per agent. That doesn't scale either: each new integration means a code change, a redeploy, and more prompt.

The solution: a tool registry behind four meta-tools

Runstack splits tools into two layers:

What this buys you:

• Fixed context size. It's the same four tools whether the registry holds 40 tools or 4,000.
• On-demand metadata. Only the tools relevant to the current task ever enter the conversation.
• Zero-redeploy growth. New toolkits land in the registry, and agents find them through search with no code change on the integrator's side.
• Better tool choice. The model reasons over a handful of search results instead of a wall of schemas.

<Mermaid

chart={`sequenceDiagram

participant U as User

participant L as LLM + meta tools

participant E as Execution layer

participant R as Tool registry

U->>L: "Create a Linear issue: Fix checkout timeout"

L->>R: search_tools({ query: "linear create issue", expand: "createIssue" })

R-->>L: top-5 matches + full schema

L->>E: check_authentication("createIssue")

E-->>L: connected ✓

L->>E: execute_tool("createIssue", {...})

E->>R: inject token server-side & run

R-->>E: { identifier: "ENG-482", url: ... }

E-->>L: tool result

L->>U: "Created ENG-482."

`}

/>

When the user isn't connected yet, initiate_connection returns a link. The user completes OAuth once, and from then on the agent runs the tool directly.

Product surfaces

Runstack exposes one execution layer through several surfaces, so teams can use it wherever their agents live.

<BlogSectionImage src={chatImage} caption="https://runstack.engineer workspace runstack agent" />

Runstack Agent: workspace chat

The main app at / is an agent that works across every toolkit you've connected, plus any external MCP servers you've added.

Composer

• Attachments: images (JPEG/PNG/GIF/WebP) and documents (PDF, TXT, CSV, Markdown), up to 10 MB each.
• Context popover: toggle Firecrawl web search and scraping (on by default, with sources and favicons in the answer), toggle individual external MCP servers per message, and Runstack KBrain (coming soon).
• @ mentions to target toolkits and search tools; / commands to run a published Studio agent.
• message rails for quickly navigating to the past messages in a chat.

Models: any LLM, bring your own key

• Auto model selection (default), or pick a specific model grouped by provider: Cloudflare Workers AI, OpenRouter, Google, Anthropic, OpenAI, with Tools and Reasoning capability badges.
• Settings → LLM Providers: bring your own keys (stored encrypted), test the connection, add custom model IDs, toggle "show in chat", and set a workspace default model and a separate Bot model for embedded widgets.

Transparency in every message

• Tool-call chain: each call's JSON input and output plus running/completed/error state. Choose List or Compact pill mode.
• Reasoning blocks with duration, and token usage per message.
• Copy, retry, and download as Markdown.

Conversation management

• Pinned, Recents and Archive; rename; delete.
• Public share links (/chat/share/{id}), viewable without signing in.
• Auto-generated chat titles; ⌘K workspace search; ⌘O new chat; D toggles the theme.

Workspace Instructions (Settings → Instruction)

• Per-workspace agent instructions stored in WorkspaceInstructions (workspaceId unique, content up to 8,000 chars, timestamps).
• Injected into every main chat as a Workspace instructions (follow for every response in this workspace): block appended to the system prompt. Empty content is skipped.

<BlogSectionImage src={studioImage} caption="https://runstack.engineer studio for agent creation" />

Runstack Studio: agents and marketplace

Studio turns tool sequences into reusable agents.

• Agent = role + workflow. The role (description) becomes the runtime system prompt. The workflow is an ordered set of tool steps with conditions: Condition, Condition Branch (if/else), and Multi Condition.
• Two synced editors: a Form (nested step tree with numbered steps like 2.1) and a visual Workflow canvas (drag toolkits, connect nodes).
• Studio assistant: a chat panel that edits your draft for you ("add a GitHub step to fetch the latest PR, then review only if there are changes") using tools like addToolStep, addCondition, updateAgentMetadata and searchTool.
• Versioning and publishing: drafts, v1.0 → v2.0, published agents are read-only (use Make a copy to change them), and 21 marketplace categories (Engineering, Sales, Support, Finance & ops, and more).
• /command system: every published agent gets a camelCase slash command (PR Reviewer → /prReviewer) that you invoke in any chat.
• Marketplace: browse every published agent, explore its workflow, and run it. The landing page's Use cases section is fed live from the marketplace.
• Use agents outside Runstack: each agent has an id. Pass agentIds to @rnsk/tools or @rnsk/bot to scope tool discovery to that agent's toolkits, and use fetchRunstackAgent() + buildAgentSystemPrompt() to reuse its role.

Workflow steps guide the loop rather than hard-code it: the agent can still use the meta-tools to discover extra tools when a task needs them.

<BlogSectionImage src={ossRegistry} caption="https://www.npmjs.com/package/@rnsk/toolkits — OSS toolkits registry" />

Toolkits and the open-source registry

A toolkit is a bundle of tools for one product, described by a single declarative manifest: id, display name, category, icon, auth spec, tool list, per-tool scope (read / write / delete) and allowedHosts.

Available today (@rnsk/toolkits@0.0.12, 60 toolkits / 2,619 tools) as of 23rd Sep 2026

Seven auth modes, all declarative — see packages/toolkits/src/core/types.ts:60 (ToolkitAuthSpec):

none oauth2 service_env api_key basic_auth bearer_token service_account. Each manifest declares auth.type, tokenField, and a provider spec (types.ts:36); validate.ts:27 enforces requiredAuth consistency. The OAuth/token exchange is performed by Runstack from the manifest data — contributor code never touches client secrets.

Community-driven, open source (rnsk-toolkits monorepo):

• packages/toolkits: the published package, with defineToolkit / defineTool helpers and validate checks.
• Contributor sandbox (npm run sandbox): runs local, unbuilt toolkit source through the real @rnsk/bot widget with the same meta-tool flow as production, using a free Gemini or OpenRouter model.
• Private toolkits: fork or publish a scoped package and point your deployment at it (Enterprise: custom toolkits).
• Shipping to Runstack: a single version bump of @rnsk/toolkits in the server picks up every new toolkit.

Request an integration: users request a new toolkit or new tools inside an existing one from the app. Runstack files a GitHub issue automatically with an LLM-drafted description, tracks it (RQ-… ids, status, dedupe, optional attribution), and closes the loop when the integration ships.

Per-workspace connections: OAuth tokens are stored per workspace, so a personal GitHub in one workspace and a work GitHub in another both work.

Developer integrations

<BlogSectionImage src={mcpImage} caption="https://runstack.engineer/docs/mcp-tools — Connect our mcp server to any client" />

MCP server: any MCP client

POST https://app.runstack.engineer/mcp (Streamable HTTP, JSON-RPC, Authorization: Bearer rnsk_…). It exposes the four meta-tools. Guides exist for Cursor (one-click deeplink), VS Code, Antigravity, Claude Desktop, Claude Code, ChatGPT, Codex CLI, and custom agents (TypeScript MCP SDK, Python, Go, curl). CORS is enabled for browser clients.

@rnsk/mcp: stdio bridge

{ "mcpServers": { "runstack": { "command": "npx", "args": ["-y", "@rnsk/mcp"], "env": { "RUNSTACK_API_KEY": "rnsk_..." } } } }

@rnsk/tools: one line for any AI SDK app

await generateText({
  model,
  prompt: "Star vercel/ai on GitHub and email me a confirmation",
  tools: runstackTools(process.env.RUNSTACK_API_KEY!),                // everything
  // tools: runstackTools(key, { toolkitIds: ["github", "gmail"] })   // scoped
  // tools: runstackTools(key, { agentIds: "agent_…" })               // scoped to a Studio agent
})

@rnsk/bot: a chat UI in minutes

> An interactive demo is available in the web docs.

@rnsk/tui: chat in the terminal

npm i -g @rnsk/tui
rnsk auth login   # paste rnsk_…
rnsk chat --toolkit github --toolkit notion
# rnsk chat --agent agent_…   # scoped to a Studio agent

Same API-key auth and meta-tool flow as the web app, rendered as a terminal UI (Enter submit, y/n approve tools). When a tool needs OAuth, open the returned link, connect in the browser, then type "connected".

<BlogSectionImage src={wsImage} caption="https://runstack.engineer setting page" />

Platform: teams, security and operations

Organizations and workspaces

• Personal or Team organizations. Team orgs create multiple workspaces and invite members (in-app invitations with accept/reject notifications).
• A workspace isolates chats, agents, toolkit connections, API keys, MCP servers, LLM settings, guardrails, instructions and branding, and it's selected per request with X-Workspace-Id.

API keys

• rnsk_ + 64 hex characters, stored as SHA-256 hashes, shown once, workspace-bound.
• Per-key usage bar (warns at 80%, blocks at 100%) and last-used time.
• Only execute_tool counts; searching, checking auth and connecting are free.

Security: tokens never reach the LLM

• OAuth tokens and service keys live in Runstack's execution layer and are injected at execution time. The model only ever sees sanitized results.
• Guardrails (per workspace): secret redaction, PII scrubbing, blocked-tool and allowed-tool lists, and a max-tool-calls-per-turn cap.
• Instructions (per workspace): workspace-wide agent guidance injected as a dedicated system-prompt section on every chat turn.
• Auth — Clerk (@clerk/react on the client; @clerk/express on the server).

Telemetry

• Logs show total requests, executions, errors and success rate.
• A 14-day activity chart and a per-request table (method, tool, API key, status, counted).