Dynamic MCP server

LIVE · v0.3.14 STANDARD · 4 EXPERIMENTALApache-2.0

heku

One MCP server. Any API. Any LLM.
Describe an integration as JSON. heku serves it as a tool your agent can call. GitHub, Stripe, Linear, internal REST: one config each, one server total.

Open console →Read docs View source

›npx @rapidthoughtlabs/heku start

›npm install -g @rapidthoughtlabs/heku

›heku start --http --port 3456

Most MCP servers are thin HTTP wrappers. You do not need a new one every time.

Roughly 85% of MCP servers are HTTP proxies around an existing API. Another 10% wrap CLI commands. Only about 5% need their own runtime. heku covers the 95% with JSON configs on one server, so you stop paying the per-integration tax in manifest size and ops time.

WITHOUT HEKU

mcp — bloated manifest

10 integrations → 10 MCP processestools/list → ~30,000 tokens at connectnew API → new repo + deploy cyclemanifest grows with every server you add›

WITH HEKU

heku — lazy discovery

10 integrations → 1 heku processtools/list → 529–757 tokens at connectnew API → drop JSON config, hot reload✓ O(1) cold connect regardless of config count›

Add a tool, not a deployment.

See it running

Install in one command.

Point the hosted console at localhost.

Chat with your tools without wiring a client.

Config in. Tools out.

Write a config.

JSON describes the connector type and each tool call. GraphQL, gRPC, and child-MCP configs can leave tools empty and heku introspects the source.

Start heku.

One server loads every config. Credentials live in .env files per service, not in your MCP client JSON.

Agent calls tools.

Lazy discovery keeps the cold-start manifest small until the agent searches for what it needs.

COMPLETE INTEGRATION — rickandmorty-graphql.json

rickandmorty-graphql.json

{

"id": "rickandmorty-graphql",

"name": "Rick & Morty",

"connector": {

"type": "graphql",

"endpoint": "https://rickandmortyapi.com/graphql"

"tools": []

}

// tools: [] is not a typo — heku introspects and fills tools on load

What people build with heku

Agent harness

Wire Cursor or Claude to GitHub, Slack, and Linear without maintaining three separate MCP servers.

github-http · slack-http · linear-graphql

Internal APIs

Turn hundreds of internal REST endpoints into agent tools with JSON configs, not a new microservice per team.

Hosted gateway

Run heku once on a server; agents connect over HTTP from anywhere — no local MCP process per machine.

Share and install

Publish a config to heku hub. Anyone installs with one command and their agent can call your API.

heku install @rtl/githubBrowse heku hub →

Want the full story on lazy discovery and self-authored configs? Read the launch post.

Two hundred configs. Same cold-start cost.

Traditional MCP loads every tool schema at connect. heku's discovery handshake is O(1) regardless of config count — flat or namespaced naming, same bounded manifest. Service tools are found on demand via search.

TOKEN COST AT COLD CONNECT

cold connect — token budget

// Namespaced discovery — meta-tools only at connect

tools/list 529–757 tokens

"Install 5 configs or 200. Connect cost barely moves."

// O(1) manifest handshake regardless of config count

MANIFEST STYLE — heku.config.json

heku.config.json

{

"manifestStyle": "flat",

"self_config": true,

"log_level": "info"

}

// flat: native tool names for Cursor / Claude

// namespaced: config_id.tool_name for custom harnesses

Eight connector types, one config format.

Each config sets a connector.type and connection details. Arrow through the types below to see each shape.

Standard — remote APIs & MCP servers

GraphQL — introspect at startup

Leave tools empty and heku introspects the schema on load. Queries and mutations show up in the manifest without hand-written definitions.

shopify-graphql.json

{

"id": "shopify-graphql",

"name": "Shopify Storefront API",

"connector": {

"type": "graphql",

"endpoint": "https://your-store.myshopify.com/api/graphql",

"auth": {

"type": "bearer",

"token_env": "SHOPIFY_STOREFRONT_TOKEN"

}

Console and heku hub

Run heku locally, then use the hosted console against your instance. Install community configs from heku hub without hand-rolling JSON.

Console

Chat with your tools, edit configs, inspect prompts, and check auth status for every connector.

Open console →

heku hub

Browse community configs, install with one command, and publish your own integrations.

Browse heku hub →

INSTALL FROM HUB

heku install @rtl/linear

heku install @rtl/slack@1.2.0

heku publish ./my-config.json

Let the agent write its own configs

The same meta-tools that power lazy discovery let an agent hand itself a new capability mid-conversation. Disable write access in console settings when you want a fixed integration set.

Encounter

The agent meets a system it has no tools for. You drop in API docs, an OpenAPI spec, or a few cURL examples.

Author

The agent calls heku.create_config and writes the JSON itself: endpoints, auth, tool names, inline.

Hot reload

The file watcher picks up the new config. The server stays up. Existing tools stay live. No restart.

Call

By the next user message, the new tools are callable. Same session, same client, no human in the loop.

See it in action: heku writes an OpenRouter config from live docs.

Built in from day one

built-in modules

heku.status5/5 online

JSON-defined tools

json-tools

Describe a tool in a few lines of JSON. No SDK to learn, no framework to wire up, no code to maintain.

{

"name":: "list_repos",

"method":: "GET",

"path":: "/user/repos"

}