The Hypothesis

Can a thin CLI layer conserve agent context by letting AI discover and call tools on-demand instead of loading everything upfront?

The Concept

AI agents burn context loading tool schemas, database configurations, and MCP server definitions upfront — most of which they never use in a given session. Quiver flips this: a single CLI that lets agents discover, inspect, and execute tools on-demand across MCP servers, databases, and shell integrations. The agent starts lean, searches for what it needs (`yeet search "list repos"`), inspects the schema, and calls the tool — all through one interface. Context stays minimal. Tool access stays universal.

Quiver

The hypothesis

Can a thin CLI layer conserve agent context by letting AI discover and call tools on-demand instead of loading everything upfront?

The concept

AI agents burn context loading tool schemas, database configurations, and MCP server definitions upfront — most of which they never use in a given session. Quiver flips this: a single CLI that lets agents discover, inspect, and execute tools on-demand across MCP servers, databases, and shell integrations. The agent starts lean, searches for what it needs (yeet search "list repos"), inspects the schema, and calls the tool — all through one interface. Context stays minimal. Tool access stays universal.

How it works

1. Agent needs a capability — e.g. “list GitHub repos” or “query the database”
2. Search via CLI — yeet search "list repos" finds the right tool across all MCP servers
3. Inspect schema — yeet inspect github list_repos returns parameters without loading everything
4. Call with parameters — yeet call github list_repos '{"owner": "anthropics"}'
5. Context stays lean — agent only loaded what it needed, when it needed it

One CLI. Every MCP server, database, and shell tool. Zero upfront context cost.

What it explores

• How much context can be saved by on-demand tool discovery vs. upfront schema loading?
• Does the discover → inspect → call pattern add meaningful latency vs. pre-loaded tools?
• Can agents reliably find the right tool via search without knowing exact names?
• Does a unified CLI reduce integration complexity when agents work across multiple MCP servers?
• What’s the right balance between pre-loaded context (fast) and on-demand discovery (lean)?

What we found

• Context usage dropped 60–70% for typical agent sessions
• The discover → inspect → call pattern added ~200ms per tool invocation — negligible for most workflows
• Agents found the right tool via search 89% of the time on first attempt
• The unified CLI eliminated the need for per-server integration code
• The server registry made adding new capabilities a one-line operation

Learnings

• Agents describe what they need, not what the tool is called — search-first discovery aligns with how agents naturally express intent.

• Always provide a --json flag for machine-readable output — agents parse structured output far more reliably than human-formatted text.

• Unify database operations (queries, schema inspection) into the same CLI as tool calls — it eliminates a whole class of separate integrations.

• The pattern generalises beyond tools: any resource an agent might need (tools, data, configs) benefits from on-demand access over upfront loading.

• One-command add/remove for server registries lowers the barrier to expanding agent capabilities — make capability growth a one-line operation.

Where it goes next

Quiver is being integrated into AgentOS as the default tool access layer. The discover → inspect → call pattern is also informing how Orchesta’s skill registry works — the same principle of lazy loading applies to skills, prompts, and templates, not just tools.