Interactive · no install · play in your browser

Give your agent 300 tools.
It only ever sees 3.

OKTS is a source-agnostic wrapper that turns any pile of tools — MCP servers, functions, HTTP APIs, sub-agents — into a searchable catalog behind a stable 3-tool interface. This page lets you feel the difference. Play it.

▶ Start — feel the flood Skip to the game

Act 1 · the problem

The more tools you load, the dumber the agent gets

Every tool you bind to an agent ships its full JSON schema into the context window — before the task even starts. Drag the slider and watch the cost.

24 tools bound

context eaten

—

schema tokens

—

near-dup clusters

—

of a 128K context window

What actually goes wrong

This is the agent's context before it reads your prompt:

🟨 Near-duplicates — search_issues, list_issues, find_issues_by_label — blur together, so the model picks wrong or invents parameters. 🟥 Attention dilutes across definitions it will never call.

Act 2 · the fix

Progressive disclosure: the agent sees three tools, forever

OKTS keeps the whole catalog outside the context window and hands the agent a tiny, fixed menu. The agent searches for what it needs, loads one schema on demand, then calls it.

search_tools(query, k=5)rank · returns refs
load_tool(id)fetch ONE schema
call_tool(id, args)validate + dispatch

That's the entire tool surface — whether the catalog holds 3 tools or 3,000. The schema footprint is flat. The context you saw fill up in Act 1 never happens.

tools in context

schema tokens

~600

grows with catalog?

The three phases

search — ranks tools on their human-readable prose (description + body + tags), prefilters by category, and graph-expands to surface alternatives. Returns lightweight refs, not schemas.
load — injects the one structured input_schema the agent chose.
call — validates args against that schema and dispatches to the real source. Credentials stay inside OKTS and never enter the agent's context.

▶ Play the loop yourself

Act 3 · you are the agent

Play the search → load → call loop

You've been handed a task. Search the catalog in plain language, open the one schema you want, fill it in, and call. Watch the right-hand "agent context" stay tiny.

🎯 Your task: Find the open issues in your repo that are labelled bug.

try:

🧰 Your catalog — toggle sources on/off; every number below reacts

Interfaces in play: mcp · http · function · search · agent — one uniform catalog, five very different backends.

phase 1 · search_tools

Type a task above (or tap a suggestion) and hit Search.
Only descriptions come back — zero schemas loaded.

Session HUD

catalog

–

sources

–

schemas loaded

context · OKTS

–

Agent context — with OKTS

3 tools

Same task — without OKTS

The format · OKT

Every tool is one portable, git-versioned markdown file

An OKT file is YAML frontmatter + a prose body. The frontmatter is grouped by the runtime phase that consumes it — so an opened file is self-documenting. This is a real file OKTS emits.

# identitytype: tool id: github-mcp.search_issues title: Search Issues

# match — ranked by search_tools (phase 1); never sent at call timedescription: Full-text search across a repo's issues by keyword, label, state, or assignee. tags: [github, issues, search, triage]

# call — loaded by load_tool (phase 2); the calling contractinput_schema: type: object required: [query] properties: query: {type: string} state: {type: string, enum: [open, closed, all]}

# route — used by call_tool to dispatch (phase 3)interface: mcp target: github-mcp auth: env:GITHUB_TOKEN # resolved inside OKTS — never sent to the agent side_effects: read_only invocation: async

# graph edges — expanded during search_toolsalternatives: [github-mcp.list_issues]

# body — retrieval prose, not a contractUse this to triage. Prefer it over list_issues when the user gives a keyword or label. Returns lightweight issue refs.

identity match → search call → load route → call edges → graph

Five invariants that never bend

1 · exactly 3 tools

The agent-facing surface is always search/load/call — no matter how big the catalog grows.

2 · structured input_schema

The call contract is always a real JSON Schema, so args can be validated before dispatch.

3 · body is prose, not contract

The markdown body is retrieval text for ranking — never the thing you call against.

4 · credentials stay inside

Tokens/keys resolve within OKTS at dispatch. They never enter the agent's context window.

5 · minimal frontmatter

Six required fields: type · id · title · description · input_schema · interface. The rest is optional.

Recap

Same tools. Two very different agents.

These numbers track the catalog you assembled in Act 3 — toggle sources up there and watch them move.

Without OKTS

—

With OKTS

~600 tokens

Three meta-tools, flat forever. One schema loads only when the agent picks it. The catalog can hold thousands of tools and the footprint doesn't move.

Try it for real — three commands

# 1 · point OKTS at your sources (tools.config.yaml)
sources:
  - interface: mcp
    servers:
      github-mcp: {command: npx, args: ["-y","@modelcontextprotocol/server-github"]}
  - interface: function
    module: ./my_tools.py
retrieval: {mode: hybrid, graph_expand: true, k: 8}
bundle_dir: ./okt-bundle

# 2 · build the catalog once (connects, ingests, enriches, auto-links, validates)
okts-build --config tools.config.yaml

# 3 · serve it — any MCP client now sees 3 tools instead of 300
{ "mcpServers": { "okts": { "command": "okts", "args": ["--bundle-dir","./okt-bundle"] } } }