AutoMCP: Inferring Parametric Macros from Typed Action Graphs

1. Introduction

Macros are old. Lotus 1-2-3 shipped a recorder in 1983; vim’s q<reg>...q and emacs’s kmacro-start-macro predate that in spirit. The shape of all of them is the same: the user records, the system replays, and parameterization — if any — comes from positional substitution on a character stream the recorder treats as opaque. None recognize a macro the user has not explicitly recorded.

Modern coding tools do better in narrow ways. Copilot CLI suggests command sequences from its training corpus; Cursor’s “extract this” wraps a selected region as a function; JetBrains’ “introduce method” infers parameterization from local data flow. These are single-shot suggestions over visible code, not background recognition over a long-running execution stream.

AutoMCP is the macro layer for Memagen™‘s tool surface. It is a background recognizer that observes which tools the agent uses, in which sequences, with which argument shapes, and proposes named parametric macros when a stable pattern emerges. Approved macros are added to the agent’s tool catalog and dispatched exactly like any other tool — internally, the macro runs the underlying sequence, with arguments substituted into the template positions the recognizer identified.

The novelty is the input. AutoMCP operates over a typed action graph: every action is a node carrying a tool name and an argument dictionary that conforms to that tool’s MCP schema; edges are temporal between consecutive actions. Recognition over a typed graph is structurally easier than over a flat trace, because the graph’s parameterization candidates are explicit argument positions rather than positional guesses on a character stream. Three observations of a structurally identical sequence with one varying argument are enough evidence that the position is a parameter; a keystroke recorder needs dozens and still produces ambiguous macros.

This paper documents the open-core (V1-lite, MIT) implementation. We follow the Memagen™ master paper (Levitas, 2026a) conventions: no marketing claims, file paths cited where they exist in the source tree, candid scope limits. AutoMCP composes with two siblings documented separately — UIMCP (Levitas, 2026b) compresses which tools the LLM sees per turn, AutoWebMCP (Levitas, 2026c) generates MCP wrappers from arbitrary web pages — both produce nodes that AutoMCP’s recognizer treats uniformly.

2. Related work

2.1 Programming by demonstration

Programming-by-demonstration (PBD) is the foundational literature. Cypher’s anthology Watch What I Do (Cypher, 1993) collected Halbert’s SmallStar, Lieberman’s Tinker, Myers’s Peridot. The classical difficulty is inferring intent from extension — the user shows a few examples, the system must guess which dimensions of variation matter. PBD made progress with generalization-by-example (Witten & MacDonald, 1988) and version-space algebra (Lau et al., 2003) but never produced a robust general-purpose system. The recurring observation is that strong type information makes inference dramatically easier (Cypher, 1993, ch. 1; Lau et al., 2003) — exactly the input AutoMCP gets from MCP’s typed schemas.

2.2 Repetition detection in command logs

Allen et al. (2005) and later command-history-mining work treated .bash_history as the input and proposed alias suggestions. These systems work on a flat command line; parameterization is inferred from string-edit distance between adjacent occurrences. The aliases that emerged were typically zero-argument constants (alias gst='git status') — parametric inference over flat strings is unreliable.

2.3 Modern AI-coding macro analogues

• GitHub Copilot CLI (2024) suggests parameterized command templates from its training corpus rather than the user’s history.
• Cursor’s “extract this” converts a selected region into a function — single-shot, LLM-assisted, not a background recognizer.
• JetBrains’ refactorings (Introduce Variable / Method / Parameter) infer parameterization from data-flow analysis of a single selection; they do not aggregate across sessions.

None are background recognizers over multi-session execution traces.

2.4 Voyager-style skill libraries

Voyager (Wang et al., 2023) showed that an agent in Minecraft could write skills as code and accumulate them in a library. The skill-write step is goal-driven: the agent writes a skill when a goal is reached, not when a structural repetition is detected. AutoMCP is the dual — pattern-detected rather than goal-detected — and could compose with a Voyager-style approach, where AutoMCP proposes the skeleton and an LLM step writes the body.

2.5 Why agent-targeted macro inference is different

The structural difference is the input: a typed action graph rather than a flat trace. Each action carries (a) a stable tool name, (b) an argument dictionary whose keys and value-types conform to the tool’s MCP schema, and (c) a recorded outcome. The matcher’s predicate is “same tool, same other-argument values, varying value at position k” — a direct query over the graph. The flat-trace equivalent is “same prefix, same suffix, varying middle bytes,” solvable in principle but noisy in practice.

3. The recording layer

Every successful tool dispatch in Memagen™ produces an entry in an execution-trace log. The trace structure is in core/mcp/evolution.py as ExecutionTrace:

ExecutionTrace {
  tool_name: str          # e.g., "github.search_repos"
  tool_cid: str           # content-addressable id of the tool definition
  parameters: dict        # canonical-shape arguments after parser coercion
  outcome: ExecutionOutcome  # SUCCESS | PARTIAL | FAILURE | TIMEOUT
  latency_ms: float
  token_usage: int
  user_feedback: str | None
  timestamp: float
  error_message: str | None
}

The tracer (ExecutionTracer.trace_execution in the same file) appends each trace to an in-memory list under a thread-safe lock and updates a ToolScore running summary keyed by the tool’s content id. AutoMCP consumes the same trace stream as the per-tool evolution engine; we deliberately did not duplicate the recording machinery.

For UI-level macros — the structured DSL the agent emits to drive UI applications through UIMCP (Levitas, 2026b) — the recording structure is MacroStep in core/tools/uimcp_macro.py. The DSL has a closed verb table of 16 ops: click, click_at, double_click, right_click, type, key, nav, launch, use_app, focus_app, move, scroll, screenshot, verify_screenshot, sleep, and the per-step on_error directive. Hard caps are enforced at run-time: _MAX_MACRO_STEPS = 500 and _MAX_MACRO_WALLCLOCK_S = 600.0 (uimcp_macro.py:380-381).

MacroStep {
  op: str           # one of the 16 closed verbs above
  args: list[Any]   # positional arguments after shlex-tokenization
  on_error: str | None  # per-step override of the macro's policy
  line_no: int
  raw_line: str
}

Successful UI macro runs are persisted as graph nodes of kind macro_run (see run_macro in uimcp_macro.py, which calls stamp_new_node with kind="macro_run" and a JSON body holding the script, summary, and per-step results). This means the same macro can be replayed verbatim by node id (replay_macro), and the same node body is what AutoMCP’s pattern recognizer reads when it scans for cross-session repetitions over UI-level operations.

A typed action graph in this paper is the union of these two streams: tool-call traces (one node per ExecutionTrace) plus structured UI macro runs (one node per macro_run, which is itself a sequence of MacroSteps). Both share the property that every node is addressable by a tool name (or DSL verb) and an argument dictionary, which is what makes structural matching possible. AutoWebMCP-generated tools (Levitas, 2026c) appear in the same stream as ordinary ExecutionTrace nodes, so a routine that mixes hand-written MCP tools, AutoWebMCP-synthesized HTTP tools, and UIMCP UI verbs is a single homogeneous opcode sequence to the recognizer.

Stream cost. A canonicalized opcode entry — verb token, packed argument tuple, outcome enum, monotonic timestamp delta — is roughly 40 bytes on disk after structural compression. A raw screen-and-keystroke transcript covering the same UI step (screenshot blob, mouse coordinates, modifier-key state, keystroke ring) is ~2 KB before compression and ~400 bytes after. The opcode stream is ~50× smaller than a raw transcript and ~10× smaller than a compressed one, which matters because cross-session matching reads the entire persisted history and the matcher’s O(N·L·max_length) cost is dominated by N. K=1024 in the in-memory ring (configurable via env) is chosen so the typical session fits without spilling.

The recording buffer is a bounded ring of the last K actions in the current session. Cross-session matching reads from the persisted graph; the in-memory ring is the fast path for within-session detection.

3.1 The recording-and-replay pipeline

The end-to-end shape:

flowchart LR
    A[User action sequence<br/>click, type, nav, key,<br/>launch, scroll, ...] --> B[Recorder<br/>ExecutionTracer +<br/>macro_run graph nodes]
    B --> C[Opcode stream<br/>typed action graph<br/>~40 B/step]
    C --> D[Pattern matcher<br/>n-gram + arg-template<br/>+ outcome stability]
    D --> E[Proposal queue<br/>stability >= 0.7<br/>SQLite-backed]
    E -->|approve| F[Macro catalog<br/>ToolDefinition,<br/>MCP schema]
    F --> G[Playback engine<br/>substitute params,<br/>per-step capability gate]
    G --> H[Reproducible action chain<br/>across sessions]
    H -.cross-session.-> C

The dotted feedback edge generalizes macros across sessions: an approved macro registered as a ToolDefinition appears as a single opcode the next time the user invokes it, so higher-order patterns become detectable on top. (V1-lite does not yet exploit this; §8.6 calls it out.)

4. Pattern recognition

AutoMCP fuses three signals to decide whether a candidate sub-sequence deserves to be proposed as a macro. All three must be present at non-trivial strength; none is sufficient alone.

4.1 Sequence n-gram

Subsequence repetition: two-or-more consecutive tool calls in the same order, occurring at least N times across the observation window. The window is the session for in-session matching; for cross-session matching, it is the persisted action history bounded by the user-configured retention horizon.

The matcher walks the trace stream and, for each pair of indices (i, i+L) and (j, j+L) with i < j and L between 2 and a configured max_macro_length (default 8), checks whether the tool-name sequences agree. When they do, the candidate’s frequency count is incremented. A candidate that does not reach min_frequency (default 3 within a session, 5 across sessions) is dropped. The matcher is unoptimized — O(N · L · max_length) where N is the trace length, run after each new action is appended. Section 8 lists this as a known limitation.

4.2 Argument templating

A repeated tool-name sequence is necessary but not sufficient. The matcher then asks: across the matching occurrences, which argument positions vary and which are stable?

For each tool position the matcher computes the set of argument-value-tuples observed across occurrences. Identical across all occurrences is a constant. Varying but type-consistent (per the tool’s MCP schema) is a parameter candidate. Unrelated noise — different types, no recognizable pattern — disqualifies the candidate, on the assumption that the variation is coincidental rather than parametric.

The output is a macro template: a sequence of (tool_name, argument_dict) pairs with each argument either bound to a constant or marked as a parameter slot, parameter slots carrying the inferred type from the schema. A candidate with zero parameter slots becomes a constant macro. A candidate with more than max_parameters (default 5) parameter slots is dropped — beyond that the macro is essentially the original sequence with no abstraction value.

The matcher does not attempt to merge structurally similar candidates into a single template with optional arguments. Two candidates that differ in one tool call’s presence are kept as separate proposals; the user decides at proposal time.

4.3 Outcome stability

The third signal asks whether the macro reliably reaches a success state. For each occurrence the matcher checks the recorded ExecutionOutcome of every tool call. A stable macro has SUCCESS outcome on every step in at least min_stable_fraction (default 0.8) of its occurrences. A macro whose terminal step frequently produces PARTIAL or FAILURE is filtered out: turning a half-failing pattern into a named tool would surface a tool that fails reliably.

A macro whose middle steps fail occasionally but whose terminal step succeeds (because of retry or alternative branching) is also filtered — AutoMCP does not yet handle branching (§8.4).

4.4 Composite stability score

stability(candidate) =
    min(1.0, frequency / required_frequency)
  * min(1.0, parameter_consistency)
  * outcome_success_fraction

A candidate whose stability score exceeds the proposal threshold (default 0.7) becomes a pending proposal. The threshold is hand-tuned; we have not done sensitivity analysis. §9 says so explicitly.

5. Proposal UX

A pending macro is presented to the user as a structured proposal:

You ran the following sequence 6 times this week:

1. github.search_repos(query=$1)
2. github.view_repo(name=...)
3. github.clone(url=...)

The first call’s query argument varied across occurrences; everything else was the same shape, and the sequence reached SUCCESS in every case. Should I save this as a clone_searched_repo(query) macro?

The proposal includes:

• The candidate macro template, with parameter slots highlighted.
• A summary of how many times the sequence occurred and over what time window.
• The success rate.
• A suggested name for the macro (rule-based: take the verb from the terminal step, append the most variable argument’s name as the suffix). The user can rename.

The user can:

• Approve — the macro is added to the catalog as a first-class tool. Its MCP schema is generated from the parameter slots; its description is auto-filled and editable; its dispatcher is the underlying sequence runner.
• Approve with edits — same as approve, but the user has changed the name, the parameter list, or the description.
• Reject — the candidate is dropped and added to a do-not-propose-again set keyed by the candidate’s structural hash. The set is per-user and persistent.
• Defer — the candidate stays in the queue for a future review session.

Once approved, a macro is invoked exactly like any other tool. From the LLM’s perspective, clone_searched_repo("memagen") is a single tool call with one argument. From the runtime’s perspective, the macro dispatcher expands the call into the underlying sequence, substitutes the argument into the parameter slots, and runs the sequence through the same capability-gated dispatch path that any direct tool call would use. The capability check happens once per underlying tool call, not once for the macro as a whole — a macro is not a capability-bypass mechanism.

6. Implementation

The V1-lite implementation is intentionally minimal:

• Recording buffer — ExecutionTracer in core/mcp/evolution.py plus the macro_run graph nodes persisted by core/tools/uimcp_macro.py:run_macro.
• Pattern matcher — a separate module that scans the trace stream for repeating subsequences, performs parameter substitution, and computes the stability score from §4. Runs after each new action is appended, adding small but non-zero latency to every tool call (§9).
• Proposal queue — a SQLite-backed durable queue; each entry holds the structural hash, the candidate template, witnessing trace ids, and computed stability score.
• Macro catalog — an extension of the tool catalog. Each approved macro is registered as a ToolDefinition (from core/mcp/optimizer.py) whose dispatcher walks the underlying sequence. Capability requirements are the union of the underlying tools’ requirements; the V3-P capability vault sees the underlying calls, not the macro as an opaque step.
• Do-not-propose set — a SQLite table keyed by structural hash. The matcher consults this before queuing a proposal.

The matcher uses ToolContract (core/mcp/tool_contracts.py) for one specific purpose: when a candidate macro’s underlying tools have declared preconditions, the matcher copies those preconditions onto the synthesized macro so that calling the macro with arguments that violate any underlying tool’s precondition fails at pre-flight rather than mid-sequence. A macro that fails halfway through is worse than one that fails up front.

The matcher writes nothing to memory beyond its proposal queue — no tool-embedding updates, no scoring changes, no effect on the per-tool evolution loop in core/mcp/evolution.py. The two systems run in parallel, sharing only the trace stream.

7. Why typed graphs matter

Consider two recordings of the same behavior.

Flat keystroke recorder. The user types git clone https://github.com/foo/bar.git, cd bar, git pull. The recorder stores this as a 60-character string. To detect the parametric macro clone_and_pull(url), the recognizer must (a) detect that the string contains a URL, (b) detect that the URL is a parameter rather than a constant, (c) detect that the directory name bar derives from the URL, and (d) reconstruct the parametric form. Each step is heuristic. Three observations on three repos might converge; five might converge on the wrong abstraction.

Typed action graph. The same behavior is three nodes: git.clone(url="..."), shell.cd(dir="..."), git.pull(). Schemas are known. Across three observations on different repos, the matcher sees [git.clone, shell.cd, git.pull] repeated, with url varying, dir varying, and git.pull constant. The cross-argument relationship — that dir derives from url — is not inferred at this stage; both are marked as parameter slots, and the proposal becomes clone_and_pull(url, dir). Structurally less ambitious, but correct, and the user can edit the proposal at approval time to bind dir to a derivation expression.

The principle: typed graphs let the recognizer be conservative and specific. It proposes the shape it can see directly. The cost is extra parameters the user might want to tie together; the benefit is correctness on the structural pattern claimed.

A flat keystroke macro can match Ctrl+C, Ctrl+V. It cannot match “click the button labeled X, then type into the field labeled Y” because keystrokes do not know about labels or fields. AutoMCP operates over typed actions, so cross-session matching at the abstract level becomes possible: the same conceptual operation in two different application contexts produces the same structural action sequence even when the underlying mouse coordinates and keyboard events differ.

8. Limitations

1. Hand-tuned thresholds. Min-frequency, min-stable-fraction, and proposal-stability are constants in the matcher source — not adapted per-user, per-tool, or over time. A user with a high “weird one-off” rate wants a higher threshold than a user in a routine. Adaptive thresholds are §10 future work.

2. No formal correctness proof. AutoMCP does not claim the proposed macro is the right abstraction. The only correctness signal is user approval — no mechanical check that the macro’s behavior matches the user’s intent, only that it reproduces the observed sequence with substituted arguments.

3. Cross-session matching unbenchmarked. The matcher reads the persisted graph for cross-session recognition, but we have not measured at scale. The risk is that O(N·L·max_length) becomes slow on large histories; an inverted index keyed by tool-name pairs would prune the search space.

4. No branching macros. AutoMCP recognizes only linear sequences. Patterns of the form “if X, do A; otherwise do B” — common in real workflows — are not detected, and an attempted recognition that includes an early-failing branch is filtered by outcome stability rather than recognized as branching. Plausible extension; requires the action graph to record branch conditions.

5. Within-session latency. The matcher runs after each new action is appended, putting it in the agent’s hot path. On a buffer of 100 actions the per-call overhead is in the low single-digit milliseconds; on 1000, tens of milliseconds. K=1024 was chosen to keep latency under 100 ms, not on the basis of memory budget.

6. No macro composition. An approved macro is a first-class tool, but the matcher does not yet recognize sequences that use approved macros — only sequences of underlying tools. Straightforward to fix (the dotted edge in Figure 1); V1-lite does not yet do it.

7. No schema-evolution handling. If an underlying tool’s schema changes, every approved macro using it will break. The catalog has no versioning of macros against tool schemas; the user sees a runtime failure rather than a pre-flight warning.

9. Evaluation

The evaluation is candidly modest. AutoMCP has been tested in three internal sessions on the author’s working agent over a four-week observation window in early 2026.

• Sessions. Three working sessions, each ~6 hours of agent activity, density 80–120 tool calls per hour. Total observation set ~1,800 trace entries.

• Proposals generated. 14 macro candidates passed the stability threshold and entered the proposal queue.

• Proposals approved. 9 of 14 approved on first review; 2 approved with edits (renames, parameter renames); 3 rejected and added to the do-not-propose set. The rejections were two cases of “this is two unrelated things that happened to occur consecutively” and one case of “the parameter slot the recognizer flagged is not actually meant to vary — those were three deliberate retries against three test repos.”

• Latency. End-to-end matcher latency on the test agent’s typical buffer state was 2–8 ms per tool call. We did not stress-test with synthetic 10,000-action buffers.

• Stream-size savings. The opcode stream materialized for the 1,800-trace observation set was 78 KB on disk (mean 43 bytes/entry). A reconstructed raw screen-and-keystroke transcript covering the equivalent UI work was estimated at 3.4 MB before compression and 660 KB after — between 8× and 44× larger than the opcode stream. The savings come from two places: the 16-verb closed table eliminates the keystroke and mouse-event encoding entirely for UI steps, and typed argument schemas remove the screen-state context a flat recorder needs in order to disambiguate.

• Token impact in the agent loop. A macro replaces N tool-call schemas in the catalog with one. Cumulative compression from approved macros was a small fraction of the catalog token cost — measurable but not load-bearing — because the catalog was already aggressively compressed by UIMCP (Levitas, 2026b) before AutoMCP entered the picture. AutoMCP captures repeated behavior; UIMCP compresses exposure of the catalog.

• No public benchmark. There is no standard benchmark for agent-action macro inference. We did not construct a synthetic one for V1-lite; such a benchmark is more usefully designed by the field once multiple platforms ship comparable systems.

We are unwilling to claim AutoMCP “works” beyond the modest evidence: 9 of 14 internal proposals were good enough for the test user to approve. Suggestive, not conclusive. The full evaluation we would want to publish — multiple users, multiple agent domains, comparison to a flat-trace baseline, sensitivity to threshold tuning — is on the roadmap but not done.

10. Future work

In rough priority order:

• Adaptive thresholds. Track approval rate per proposal and adjust the per-user threshold so ~70–80% of proposals are approved. A small change — an additional column in the proposal table and a moving-average computation.

• Macro composition. Teach the matcher that approved macros are part of the action vocabulary. A clone_and_pull macro the user has approved should be visible to the matcher as a single action node when scanning for higher-order patterns. Structurally similar to the abstraction-level hierarchy in core/mcp/optimizer.py:HierarchyBuilder; we expect shared infrastructure.

• Macro versioning. Tie approved macros to the tool schemas they depend on. When an underlying schema changes, mark the macro as needing review rather than letting it fail at runtime.

• Cross-user macros. A pattern that emerges across many users (with consent) is signal that the pattern is generally useful. A privacy-aware aggregation pipeline could surface “users in your role often use this macro” suggestions without exposing any one user’s history. Future work — the privacy story is non-trivial.

• Branching macros. Extend the action graph to record branch conditions; teach the matcher to recognize branching patterns. Probably its own paper.

• Faster matcher. An inverted index keyed on tool-name pairs would take the matcher from O(N·L·max_length) closer to O(matches). Worth doing once cross-session matching is stressed at scale.

• Tighter integration with UIMCP and AutoWebMCP. UIMCP (Levitas, 2026b) compresses how many tool schemas the LLM sees per turn; AutoMCP compresses how many calls the LLM has to emit. AutoWebMCP (Levitas, 2026c) feeds new typed tools into the same stream the recognizer reads from — meaning a user who interacts with a freshly-wrapped web API for the third time can already get a macro proposal. The current integration is naive; tighter coupling could account for the macro’s expected downstream savings when ranking.

11. References

1. Allen, R. B., Lau, T., Weld, D. S., & Domingos, P. (2005). Programming by demonstration in the wild: Inferring shell-script abstractions from interaction histories. Workshop on End-User Software Engineering.

2. Anthropic. (2024). Model Context Protocol Specification. https://modelcontextprotocol.io

3. Cypher, A. (Ed.). (1993). Watch What I Do: Programming by Demonstration. MIT Press. The foundational anthology of PBD work, including Halbert’s SmallStar, Lieberman’s Tinker, and Myers’s Peridot.

4. Halbert, D. C. (1984). Programming by Example. Ph.D. dissertation, University of California, Berkeley. The SmallStar system, generally regarded as the first PBD system in a real productivity application.

5. Lau, T., Wolfman, S. A., Domingos, P., & Weld, D. S. (2003). Programming by demonstration using version space algebra. Machine Learning, 53(1–2), 111–156.

6. Levitas, T. (2026a). Memagen™: An Open-Core Agent Platform with Lenient Tool Routing, Capability-Gated Execution, and a Compound-Graph Memory Substrate. Memagen™ technical paper, master series. See web/site-v2/src/content/papers/2026-05-08-memagen-master.md.

7. Levitas, T. (2026b). UIMCP: Adaptive Catalog Compression for Multi-Tool LLM Agent Dispatch. Memagen™ specialty paper. See web/site-v2/src/content/papers/2026-05-08-uimcp.md.

8. Levitas, T. (2026c). AutoWebMCP: Automatic MCP Tool Schema Generation from Arbitrary Web Pages. Memagen™ specialty paper. See web/site-v2/src/content/papers/2026-05-08-autowebmcp.md.

9. Lieberman, H. (Ed.). (2001). Your Wish is My Command: Programming By Example. Morgan Kaufmann.

10. Myers, B. A. (1986). Visual programming, programming by example, and program visualization: a taxonomy. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 59–66.

11. 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.

12. Witten, I. H., & MacDonald, B. A. (1988). Using concept learning for knowledge acquisition. International Journal of Man-Machine Studies, 29(2), 171–196.

Source: https://github.com/tablevitas123/crackedclaw