UIMCP: Adaptive Catalog Compression for Multi-Tool Agent Dispatch

1. Introduction

The Model Context Protocol gives agents a clean, server-mediated way to acquire tool surfaces. As MCP adoption has grown, users routinely connect ten, twenty, or fifty servers to a single session — a code-host server, an issue-tracker server, a chat server, a filesystem server, a shell server, a browser server, plus N domain-specific tools generated via AutoMCP or AutoWebMCP. The naive approach — inject every connected tool’s schema into the LLM context on every turn — pays a token tax that scales linearly with catalog size, and which compounds across turns because tool schemas typically reside in the system prompt or a stable header that the assistant re-receives every turn.

The cost is not theoretical. A typical native tool-use schema for a non-trivial tool runs 80–200 tokens once name, description, and JSON schema are serialized. A 90-command catalog therefore costs roughly 7,200–18,000 tokens of context per turn — before the user’s message, the conversation history, the agent’s scratchpad, or any retrieved memory enters the window. On a 30-turn coding session that pattern compounds to hundreds of thousands of tokens of catalog-only billing across the conversation lifecycle. For BYOLLM (bring-your-own-LLM) deployments where the user pays the model provider directly, this is not Memagen™‘s cost to absorb, but it is Memagen™‘s cost to make small.

UIMCP — described in §9.3 of the Memagen™ master paper as the adaptive catalog compression layer — addresses this. The compression operates per-turn over three signals: recency of last tool use, embedding-similarity relevance to the current conversation context, and a discrete tier classification (always / summoned / archived). Tools in the always tier and a small meta-tool surface are injected on every turn; tools in summoned enter only after the agent calls a tools.find meta-tool that returns their schemas; tools in archived are not injected and not directly callable until promoted. On a single internal observation against a 90-command catalog over a 30-turn synthetic conversation, the result was 42.7x token compression. We describe the algorithm, the implementation, and — most importantly — the limits of what that single number actually establishes.

Section 2 surveys related work. Section 3 describes the per-turn ranking algorithm and its three signals. Section 4 describes the summoning protocol. Section 5 reports the 42.7x observation in detail. Section 6 walks the implementation: the planner, the executor, the macro layer, the framework adapters, and the optimizer pipeline. Section 7 declares evaluation limitations. Section 8 discusses the latency trade-off. Section 9 names what UIMCP is not. Section 10 lists future work. Section 11 references.

2. Architecture overview

The flow from a user-visible UI action to a tool execution is short. A click, fill, or navigation against a scanned surface is intercepted by one of three framework adapters, which encodes the action as a short opcode. The opcode crosses the MCP transport as a JSON-RPC frame; the server-side decoder resolves the opcode to a registered element record and dispatches the underlying tool, capability-gated. Per-turn injection cost is a property of the catalog the adapter exposes, not of how the action was emitted. Compression and dispatch are orthogonal concerns that share one registry.

flowchart LR
    UA["UI action<br/>(click / fill / nav)"] --> WR["web_react<br/>adapter"]
    UA --> CA["cli_argparse<br/>adapter"]
    UA --> AX["android_xml<br/>adapter"]
    WR --> OP["opcode<br/>app#elt(args)<br/>10–30 tokens"]
    CA --> OP
    AX --> OP
    OP --> MCP["MCP transport<br/>(JSON-RPC)"]
    MCP --> DEC["server decode<br/>resolve label"]
    DEC --> EX["tool execution<br/>(capability-gated)"]

    subgraph N["Per-turn catalog cost (90-command catalog)"]
        direction TB
        NAIVE["Naive injection&nbsp;&nbsp;14,237 tokens"]
        UI["UIMCP encoded&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;333 tokens"]
        NAIVE -. "42.7x compression" .-> UI
    end

Figure 1 in the rendered SVG (/papers/diagrams/uimcp.svg) shows the same flow with a side-by-side bar comparison of the naive 14,237-token injection against the 333-token UIMCP-encoded payload. The 42.7x ratio is the observation reported in §5; the structural reason it is achievable is that the opcode form names a callable rather than describing one — the description lives once on the server, not once per turn on the wire.

3. The compression algorithm

UIMCP’s per-turn ranking combines three signals into a single priority score per tool. We describe each and then the composition.

3.1 Recency

The recency signal is an exponential decay over the session’s tool-use history. Let t_n be the index of the current turn and t_use(s) the most recent turn at which tool s was successfully called. Then

recency(s) = exp(-(t_n - t_use(s)) / τ)

with τ a half-life parameter (default 8 turns in the open-core implementation). A tool used on the previous turn scores ~0.88; a tool used 16 turns ago scores ~0.14; a tool never used scores 0. The exponential shape captures the locality assumption that an agent that just used a code-host PR-creation tool is far more likely to use a sibling reviewer-add tool next than to switch to a chat tool from a different server.

3.2 Context relevance

The context-relevance signal is the cosine similarity between an embedding of the tool’s description and an embedding of the current conversation context (typically the last 3–5 turns of user+assistant text, capped at ~2,000 input tokens to the embedder). The open-core implementation uses whatever embedding the local model router has available; the master paper’s multi-provider router abstracts this so the same UIMCP run works across embedding sources.

3.3 Tier classification

A small operator-curated table assigns each tool to one of three tiers:

• always — injected on every turn. The default always set is small: shell.execute, fs.read, and the meta-tool tools.find (described in §4). Operators may add tools; the framework does not fight them.
• summoned — injected only after the agent calls tools.find and the tool appears in the result. Most tools default to this tier.
• archived — never injected and not directly callable until an operator promotes it. Useful for tools the operator wants installed but disabled for the current session (e.g., a destructive prod.deploy).

3.4 Composition

The per-turn priority for a tool s is

priority(s) = w_t * tier(s) + w_r * recency(s) + w_c * context(s)

with tier(s) mapping always → 1.0, summoned → 0.5, archived → 0.0, and the weights (w_t, w_r, w_c) defaulting to (2.0, 1.0, 1.0) so that tier dominates in ties. Tools with tier(s) == archived are filtered before scoring and never appear in the injected set even if recency and context-relevance are high.

3.5 Planner pseudocode

def select_tools_for_turn(catalog, history, conversation_context, tiers):
    scored = []
    for tool in catalog:
        if tiers[tool.name] == "archived":
            continue
        r = recency(tool, history)
        c = context_relevance(tool, conversation_context)
        t = {"always": 1.0, "summoned": 0.5}[tiers[tool.name]]
        p = 2.0 * t + 1.0 * r + 1.0 * c
        scored.append((tool, p))
    scored.sort(key=lambda x: -x[1])
    always = [t for t, _ in scored if tiers[t.name] == "always"]
    summoned_top_k = [t for t, p in scored
                      if tiers[t.name] == "summoned" and p >= SUMMON_THRESHOLD][:K]
    return always + [TOOLS_FIND_META] + summoned_top_k

In practice the open-core path is more conservative: by default only the always set and the tools.find meta-tool are injected, and summoned tools enter exclusively via §4’s protocol. Threshold-based pre-injection of high-scoring summoned tools is a configuration knob, not the default, because the default minimizes context cost at the price of one round-trip per novel tool. Both paths reflect the trade-off in §8.

The planner and the per-turn priority computation are the conceptual layer this paper documents. The closest implementation surface is core/tools/uimcp_planner.py, which shares the per-turn-recompute structure (filtering a catalog by current screen, retrieving the most-similar prior macro via _retrieve_prior_macro, and assembling a grounded prompt). The optimizer pipeline in core/mcp/optimizer.py provides upstream catalog distillation (worthiness filter, distiller, hierarchy builder, result cache) on top of which the per-turn ranker operates.

4. The summoning protocol

When the agent needs a tool in the summoned tier and not currently injected, the agent does not see that tool’s schema and cannot call it directly. Instead it calls a meta-tool tools.find(query) whose schema is always injected. The meta-tool is implemented in core/tools/mcp_optimize_tool.py as the agent-facing wrapper, with the underlying ranking living in core/mcp/optimizer.py.

The protocol on a turn where the agent needs a summoned tool:

1. Turn N (agent → meta-tool): the agent emits tools.find(query="how do I open a pull request?").
2. Turn N (meta-tool → agent): the meta-tool returns a candidate list of full schemas — the top-K matches against the query, ranked by the §3.2 context-relevance score with the query string substituted for the conversation context. K defaults to 5.
3. Turn N+1 (agent → tool): the agent now has the schemas of the top-K candidates injected for the next turn and can call any of them by name. The runtime adds the called tool’s schema to the always-injected set for the rest of the session, so subsequent turns do not re-summon — the tool is now hot.

A summoned-then-called tool is promoted from summoned-tier to always-tier for the duration of the session only. Cross-session promotion would require the catalog to learn from session histories, which the open-core distribution does not do today (see §10).

The protocol’s distinguishing property is that the agent does not need to know which tools are in which tier. The meta-tool is always available; calling it is the agent’s universal escape hatch. Tool-selection quality is preserved when the agent learns to call tools.find whenever the visible surface is insufficient — a behavior that frontier-class models pick up rapidly and that smaller models pick up less reliably (a limitation in §7).

5. The 42.7x compression observation

We state up front: this is one observation, not a benchmark. We replicate it here because it is the headline number in the Memagen™ master paper (§9.3) and the readers of that paper deserve to see how it was obtained. We do not claim it generalizes.

5.1 Catalog

The 90-command catalog used in the observation is Memagen™‘s internal default tool surface as of v1-lite, expanded to the upper end by enabling several optional MCP servers a typical power user might install. The 90 commands are sourced across three framework adapters (web_react, cli_argparse, android_xml); each adapter contributes its slice of the catalog through the same register_app path. Composition by domain:

• 14 code-host tools (issues, PRs, reviewers, branches, releases, gists, workflow runs, …)
• 9 chat tools (post message, list channels, list DMs, search, file upload, …)
• 11 issue-tracker tools (issue create/update, project list, cycle status, comments, …)
• 6 filesystem tools (fs.read, fs.write, fs.delete, fs.move, fs.mkdir, fs.list)
• 5 shell tools (shell.execute, shell.background, shell.kill, shell.ls_jobs, shell.ps)
• 8 browser tools (open, click, fill, screenshot, eval, wait, navigate, listen)
• 12 Memagen™ cognition tools (memory primitives, retrieval, dream-consolidation triggers — the Pro tier surface, counted here because the run was on a Pro machine)
• 11 Memagen™ harness tools (widget.create, workspace.apply, email.draft, email.send, code.search, code.read, code.edit, net.fetch, recipe.run, recipe.resume, capability.grant)
• 14 AutoWebMCP-generated tools from a small set of test sites (a contact form, two SaaS dashboards, an internal admin panel — fairly typical for an exploratory session)

This composition reflects what we observe in real internal use; we have not artificially padded it with redundant tools. If anything the 90 number is on the low end of what we expect production deployments to enable once Memagen™ Lite ships.

5.2 Conversation

The conversation was a 30-turn synthetic coding task: building a small TypeScript service from scratch, running tests, debugging two test failures, opening a PR, posting a chat notification, and triaging an issue surfaced during testing. The script was hand-written by the author to mirror the shape of a real Memagen™ session as closely as possible without using actual user data. We share the conversation only in the form of token counts; the script itself contains internal API references and is not in the open-core distribution.

The conversation exercises tools across multiple domains. Most of the catalog’s 90 tools are not invoked in the conversation — the regime where adaptive catalog compression has the most to offer.

5.3 Token measurement

Token counts were measured against the production tokenizer wired into Memagen™‘s multi-provider router as of 2026-05-08. For each turn we measured:

• Naive injection cost: serialize all 90 tool schemas in canonical native tool-use form and tokenize.
• UIMCP cost: serialize only the tools UIMCP injects on that turn (the always-tier set, the tools.find meta-tool, and any summoned tools promoted earlier in the session) and tokenize.

Per-turn averages over the 30-turn run:

• Naive: 14,237 tokens of catalog per turn (mean), σ ≈ 0 (catalog does not reshape).
• UIMCP: 333 tokens of catalog per turn (mean), σ ≈ 142 (the catalog grows as summoned tools promote; first turn was 211 tokens, last turn was 619 tokens).

Ratio: 14,237 / 333 = 42.7x.

5.4 Tool-selection quality

We measured tool-selection quality as a binary outcome: did the agent reach the goal (a working PR with passing tests, a chat notification posted, an issue created and assigned) in the same number of turns as the naive-injection baseline? On the single conversation tested, yes — the UIMCP run completed in 31 turns vs. the naive-injection 30 turns, the one extra turn being a single tools.find summon for an issue-tracker creation tool not in the always set. The agent’s reasoning trace did not show signs of confusion or wrong-tool selection; the summon happened cleanly on first attempt.

This is a single observation. The 31-vs-30 turn difference is comfortably within run-to-run variance for this conversation shape, and we cannot distinguish “no measurable loss in quality” from “we got lucky once” on this evidence alone.

5.5 What this is not

The 42.7x number is:

• Not a benchmark. A benchmark would require multiple catalogs, multiple conversations from a representative distribution, and ideally multiple tokenizers. We have one of each.
• Not a claim. We report the observation; we do not assert it generalizes.
• Not third-party-verified. No external party has reproduced the number against the open-core implementation. We invite the reproduction and would update this paper with replications, including replications that find smaller compression ratios on different catalogs.
• Not a guarantee of selection quality. §7 expands on this.

We present the number because the alternative — saying “UIMCP achieves significant token compression” without showing the underlying observation — would be more dishonest, not less. The reader can decide what to make of one data point.

6. Implementation notes

The open-core implementation under MIT spans six files. We describe each by responsibility and cite the function names that carry the load.

6.1 The optimizer pipeline (core/mcp/optimizer.py)

A static-analysis distillation pipeline that runs once per catalog change (a new MCP server connected, a tool’s schema updated, a tool removed). The pipeline is a sequence of named transformations:

• ToolWorthinessFilter.score(tool, existing_tools) — produces a surprise × importance × (1 − redundancy) score per tool. Tools below a default threshold of 0.3 are dropped. Surprise is 1 − parameter_count / 20. Importance is description_length / 500 capped at 1.0. Redundancy is the maximum Jaccard similarity of name-tokens and description-tokens against any existing accepted tool.
• ToolDistiller.distill(tool) — strips "This tool…" preambles, normalizes parameter names to snake_case, removes title and $schema keys from input schemas, and caps the example list at 3.
• HierarchyBuilder.build_hierarchy(tools) — classifies each tool into level 0 (raw CRUD: get/set/create/delete/update), level 1 (semantic search: search/find/locate/discover/list), or level 2 (meta: orchestrate/manage/coordinate/schedule). The hierarchy is consumed by the per-turn ranker as a tier prior — level-2 tools weight as always candidates, level-1 as summoned, level-0 as summoned with tighter recency weighting.
• ToolResultCache._compute_key(tool_name, params) — content-addressable SHA-256 over the (tool, params) pair, with a 24-hour TTL and a 1,000-entry capacity. Cache hits short-circuit dispatch entirely; this is orthogonal to compression but cooperates with it because cached calls do not advance the recency clock.

MCPOptimizer.optimize(mcp_config) runs the four phases in order and returns an OptimizedMCP dataclass with the distilled tool list, the hierarchy mapping, and the percentage token reduction.

6.2 The agent-facing optimize tool (core/tools/mcp_optimize_tool.py)

The agent invocation surface for the optimizer is exposed as the mcp_optimize tool (schema in SCHEMA, dispatched by mcp_optimize(name, tools)). Calling it persists the result as an L4 graph node (kind = "mcp_optimization"), so future sessions can recall optimization runs via graph_query("mcp optimization for code-host tools"). This is the Memagen™ pattern where every introspectable action becomes a graph fact (master paper §10.1).

6.3 The UIMCP executor and registry (core/tools/uimcp_executor.py)

The runtime that registers compressed catalogs and dispatches against them. The registry is in-memory (_REGISTRY) and persisted as L4 graph nodes (kind = "uimcp_app") via _persist_uimcp_node, so the catalog survives restarts. restore_uimcp_from_graph() rehydrates the in-memory registry on agent startup by reading every uimcp_app node from the graph database. Dispatch entry point is invoke(app, action, params), which resolves an action label to an element record (case-insensitive exact match, falling back to substring match) and dispatches to the per-framework backend.

The executor’s app notion overloads with the §3 catalog notion: an “app” is a scanned UI surface (a web app, a CLI, an Android app), and the catalog is the union of app.elements across all registered apps. The MCP-server-as-tool-source case is a special case where the elements are MCP tools rather than UI elements; the registration path is the same.

6.4 The macro layer (core/tools/uimcp_macro.py)

The macro layer records and replays multi-step tool-use sequences. It exposes a small DSL — click "X", fill "field" "value", nav "/route", plus raw mouse/keyboard ops, plus meta verbs — and a runner (run_macro) that executes parsed steps via the dispatch graph. The relevance to catalog compression is that a frequently-observed sequence of tool calls can be promoted to a single macro tool, replacing several distinct schemas in the injected set with one. The pattern matches AutoMCP’s macro inference (master paper §9.1) and provides the underlying substrate.

Persisted macros are stored as kind = "macro_run" graph nodes; the planner described in §6.5 retrieves the most-similar prior macro for replay-reuse via _retrieve_prior_macro(goal, app, top_k).

6.5 The planner (core/tools/uimcp_planner.py)

The planner drafts a macro DSL plan grounded in a real catalog. Structure mirrors the per-turn ranker:

1. _filter_by_screen(elements, current_screen) — context-relevance prefiltering. Filters the catalog to elements relevant to the current screen/route; if the filter empties the catalog, falls back to the full catalog so the planner can still produce something.
2. _retrieve_prior_macro(goal, app, top_k=1) — replay reuse. Retrieves the most-similar prior macro_run graph node for the current goal. If similarity exceeds 0.85, the planner is instructed to adapt the prior macro rather than start fresh.
3. _build_planner_prompt(goal, app, elements, current_screen, prior) — assembles a tight, grounded prompt: goal + filtered element list + (optional) prior-art DSL.
4. The LLM call goes through the multi-provider router (master paper §7).
5. _validate_plan(dsl, spec) — pre-flight validation that every click "X", fill "X" "...", and nav "X" resolves to a real element/route. Bad steps surface as warnings and the plan is marked unapproved.

The planner persists each plan as a kind = "ui_plan" graph node so future planners can recall plans across sessions.

6.6 The framework adapters (core/mcp/uimcp_adapters/)

The adapter pattern lets the same UIMCP runtime register catalogs from heterogeneous sources. Three adapters (plus a JavaScript parser) ship in the open-core distribution:

• web_react.py — scans React/JSX source for buttons, inputs, links, routes. Cooperates with the JavaScript parser jsx_parser.js for full JSX/TSX support.
• cli_argparse.py — scans Python source for argparse.add_argument calls and @click.command decorators. Source-static path: parse the AST, walk for matching call sites, extract flag names and command names.
• android_xml.py — scans Android resource XML for interactable views and resource IDs.

Each adapter exposes detect(root) (returns 0..1 confidence that this adapter applies) and scan(root, app_name) (walks the source and returns the catalog). The dispatcher detect_framework(root) picks the adapter with the highest detect score and registers via register_app. From the compression perspective, each adapter is a source of opcode-callable tool schemas; the compression pipeline operates uniformly across them.

7. Evaluation methodology limitations

We list each limitation by name, in order of how much we think it weakens the 42.7x claim.

• One catalog. The 90-command catalog reflects Memagen™‘s defaults plus a small number of optional MCP servers. A different catalog — heavier on cognition tools, lighter on code-host/chat/issue-tracker, or skewed toward domain-specific AutoWebMCP-generated tools — would produce a different ratio. We do not know how different.
• One conversation. The 30-turn coding task covers a particular slice of agent behavior. Sessions exercising more catalog breadth (debugging across many subsystems, multi-domain triage) would summon more tools and close the compression ratio. Sessions exercising less breadth (a long monologue with the same five tools) would widen it.
• One tokenizer. Token-per-character density varies across tokenizers a Memagen™ user might route to. We have not measured the ratio under any other tokenizer. The compression principle holds across tokenizers; the magnitude is tokenizer-dependent.
• Tool-selection quality measured as a binary “agent reached goal in N turns”. The weakest signal we could offer that is still a signal. A real evaluation would involve multiple independent runs, hand-graded reasoning quality, and ablation studies isolating the recency, context-relevance, and tier signals.
• No benchmark against alternative compression strategies. We have not measured UIMCP against description-pruning compression, against pure top-K retrieval-on-summon (no recency), or against a tier-only baseline. An ablation would be the right way to establish which of the three signals does most of the work.
• Smaller-model behavior with tools.find is untested. Frontier-class models pick up the call-the-meta-tool-when-stuck behavior rapidly. Smaller models with weaker tool-use generalization may not, in which case UIMCP’s compression converts directly into selection-quality loss because the agent never summons the tool it needs. The lenient parser (master paper §4) helps catch the model emitting a tool call for a tool it cannot see, but the recovery path — inject a one-shot directive to call tools.find — has not been measured against a smaller-model baseline.

We list these because the alternative is performative confidence in a single observation, which we do not believe.

8. Discussion

UIMCP trades token cost against round-trip latency. The naive baseline pays a fixed token tax per turn but never adds round-trips for tool discovery. UIMCP pays a small tax per turn (the always-tier set plus tools.find) and adds at most one round-trip per novel tool the agent needs in a session.

For sessions with stable tool usage — the agent quickly converges on a working subset and re-uses it — UIMCP is approximately free in latency: the first few turns may add summons, but once the working set is hot, the agent runs at the always-tier-plus-promoted-set cost with no further round-trips. The compression ratio in this regime is large.

For exploratory sessions — the agent moves rapidly across tools it has not used recently, summoning a new tool every few turns — UIMCP adds noticeable latency. Each summon costs one round-trip. On a model with 1.5s p50 turn latency, ten summons across a session add ~15s. The token compression remains real but the user-perceived latency degrades.

The right deployment posture depends on the workload. Memagen™ Lite ships with UIMCP enabled by default because the median session in our internal use is more stable than exploratory; operators with exploratory workloads should consider tuning the default summoned tier toward always for tools they expect to need, or pre-warming summons at session start (§10).

We note one second-order property: UIMCP improves with session length. The longer the session, the more summons have happened, the more tools promoted, the closer the catalog is to the always-tier baseline. By turn 50 of a long session, a session that started with 10 always-tier tools may have 25 hot tools — still a 4x compression against naive injection on a 100-tool catalog, but no longer 42.7x. This is the right shape: compression is largest when the cost of full injection is largest (early in the session, before the agent knows what it needs) and smallest when the agent has fully revealed its working set.

9. Comparisons we owe

UIMCP is not a tool selector. The model still selects which tool to call. UIMCP only changes which tools are visible on a given turn. A model with poor selection quality will not have its selection improved by UIMCP; if anything, a poor-selection model loses ground because the visible set is narrower.

UIMCP is not a tool synthesizer. It does not generate novel tools. AutoMCP and AutoWebMCP are the synthesis layers; UIMCP is the compression-and-dispatch layer above them. UIMCP can compress a catalog that contains synthesizer-generated tools; it does not add tools to that catalog.

UIMCP is not a permission system. The capability vault (master paper §5) is the permission system. Whether a tool is in always / summoned / archived is independent of whether the tool requires a per-use capability grant. A tool can be in always and still require a grant on every call; conversely, a tool can be in archived with no capability requirement, in which case the only thing keeping it from being called is that the model cannot see it.

These three separations are deliberate: each layer composes orthogonally, and we believe an agent runtime that fuses them (“promote the tool if and only if the user has granted a capability”) is harder to reason about than three layers with clean handoffs.

10. Future work

Five extensions, in roughly the order we expect to implement them.

Cross-session catalog warming. The current implementation discards summon history at session end. Cross-session warming would precompute the always set at session start based on signals available then: the user’s recent task history, the current project’s repository state, the time of day. Memagen™ Pro’s compound-graph memory substrate (master paper §10.1) is the natural place to land this — the graph already records tool-use history.

Provider-specific compression. Different model families have different tokenizers, different tool-use schema formats, and different tendencies to emit tools.find calls when stuck. A per-provider compression policy — different always-tier sizes, different summon thresholds, different meta-tool prompts — would let a deployment route harder workloads to frontier-class models with naive injection and easier workloads to cheaper models with aggressive UIMCP compression.

Catalog distillation: cluster-and-disambiguate. Several MCP servers expose near-duplicate tools. The optimizer’s ToolWorthinessFilter already drops tools below a redundancy threshold, but a cluster-and-disambiguate approach would expose one synthetic tool that, on call, prompts the agent to choose between underlying real tools. The compression gain on near-duplicate-heavy catalogs would be material.

Lossy schema compression for summoned tier. Applying lossy compression to the descriptions of summoned-tier schemas at summon time — preserving parameter schemas exactly, compressing the description text — would shrink the summon response further. We have not measured how much this would help.

Empirical generalization study. The most important future work is replicating the 42.7x observation across diverse catalogs, conversations, and tokenizers, then publishing the distribution rather than the single number. We expect the median compression ratio to be substantially smaller than 42.7x and the variance to be large; both are useful information for users deciding whether to enable UIMCP.

11. References

1. Levitas, T. (2026). Memagen™: An open-core agent platform with lenient tool routing, capability-gated execution, and a compound-graph memory substrate. Memagen™ master paper, 2026-05-08. memagen.com/papers/memagen
2. Levitas, T. (2026). AutoMCP: Inferring parametric macros from typed action graphs. Memagen™ specialty paper, 2026-05-08. memagen.com/papers/2026-05-08-automcp
3. Levitas, T. (2026). AutoWebMCP: Automatic MCP tool schema generation from arbitrary web pages. Memagen™ specialty paper, 2026-05-08. memagen.com/papers/2026-05-08-autowebmcp
4. Patil, S.G., Zhang, T., Wang, X., & Gonzalez, J.E. (2023). Gorilla: Large language model connected with massive APIs. arXiv:2305.15334.
5. Qin, Y., Liang, S., Ye, Y., Zhu, K., Yan, L., Lu, Y., et al. (2023). ToolLLM: Facilitating large language models to master 16000+ real-world APIs. arXiv:2307.16789.
6. Schick, T., Dwivedi-Yu, J., Dessì, R., Raileanu, R., Lomeli, M., Zettlemoyer, L., Cancedda, N., & Scialom, T. (2023). Toolformer: Language models can teach themselves to use tools. NeurIPS 2023.
7. Wang, G., Xie, Y., Jiang, Y., Mandlekar, A., Xiao, C., Zhu, Y., Fan, L., & Anandkumar, A. (2023). Voyager: An open-ended embodied agent with large language models. arXiv:2305.16291.

Source: github.com/tablevitas123/crackedclaw