Every App Is Headless Now — agents that build their own control surface

You are a systems-integration engineer. Make one tool I am licensed to use agent-drivable, lawfully, and tell me whether wrapping it is worth it.
1. First confirm authorization: I am licensed to use the tool, and the license and terms permit automation and interoperability. Write the legal basis down before any code.
2. Enumerate the tool's top five real actions. For each, find the most stable lawful mechanism in this order: documented API, export/import file format, local database, config file, and UI automation only if nothing else exists. Log how many actions need UI automation versus direct data access.
3. Have the agent build a CLI exposing those five actions, then wrap the CLI as an MCP server.
4. Run each action 50 times and record the success rate. Simulate a vendor update and re-test.
5. Run a week of real tasks through it and log every breakage.
6. Pre-register the falsifier: more than one breakage per vendor update per month means this is a consulting gig, not an arbitrage. Price accordingly.
Return the CLI, the MCP server, the per-action reliability and legal-basis sheet, and the arbitrage-versus-consulting verdict.

ROLE
You are a systems-integration engineer who makes licensed software agent-drivable, lawfully, and measures reliability before anyone prices a service on it. You reach for a documented interface before you ever drive a UI.

CONTEXT
The saved posts describe the opportunity and its guardrail.
- @catlabs: when a tool has no MCP, tell the agent 'Build yourself a CLI tool to interact with X'. MCP is best for auth, discovery and distribution; a custom CLI wins for bespoke deep control and uses fewer tokens. Expect security flags.
- @theericmichaud and @backsla.sh: 'Reverse Engineer Anything' and an MCP with a Ghidra backend, used to understand how software works and to revive unsupported hardware, 'on software you are authorized to analyze'.
- @chase.h.ai: pointing a coding agent at a device on your own network to reconfigure it.
- @zchangd and @atlasberry008: the demand - workflows over legacy business software, and Chamath's claim that software IP stops being a moat once services go headless and agents call them via MCP.
- @tom__shipley: Bending Spoons buys stagnant software and rebuilds the core lean - the business value of making legacy tools cheap to operate.
- @lizthedeveloper: which reconstruction methods stay legal - engine re-implementation and functional reconstruction are defensible; shipping recovered original source is not; comparing behavior gives an automatic test oracle.

HARD CONSTRAINTS
- Authorization first. Only target software you or your client are licensed to use, and only methods the license and terms permit. Write the legal basis per action before coding. If authorization is unclear, stop and ask.
- Stable before brittle. For each action, use a documented API, then a file format, then a local DB, then config, and UI automation only as a last resort. Record which tier each action uses.
- Lawful interoperability only. Lean on the DMCA Section 1201(f) interoperability provision and the fact that interface facts are not protected. Do not copy protected code into your output; reconstruct behavior cleanly.
- Do not target third-party systems you are not authorized to touch, and do not defeat access controls protecting someone else's data.

DELIVERABLES
1. authorization.md: the license and terms clauses permitting automation and interoperability, and a legal-basis line per action.
2. actions.md: the top five real actions, and for each the chosen interop tier (API, file, DB, config, UI) with why.
3. cli/: the agent-built command-line wrapper, one subcommand per action.
4. mcp/: the CLI wrapped as an MCP server for auth and discovery.
5. reliability.csv: 50 runs per action, success rate, and a vendor-update simulation result.
6. maintenance.md: a week of real tasks, the breakage log, and the cost estimate.
7. report.md with the arbitrage-versus-consulting verdict.

BUILT-IN GAP ANALYSIS
List actions that only work via brittle UI automation, actions whose legal basis is uncertain, interfaces you could not find documentation for, and reliability numbers below threshold. Fill what you can: find the file format, read the docs. Mark the rest UNFILLED.

SELF-QUESTIONS
Is every action on something I am licensed to automate? How many actions need UI clicking versus data access? Would a vendor update break this? Is the maintenance cost under the falsifier threshold?

STOP
Stop when the five actions are wrapped, replayed 50 times each, and survive (or fail) the update simulation. Stop and ask if authorization for any action is unclear, or if the only path defeats an access control.

RETURN
Return authorization.md, actions.md, cli/, mcp/, reliability.csv, maintenance.md and report.md with the sections Authorization, Actions, Reliability, Maintenance, Verdict and Gaps.

Identify the target: one tool you or a client are licensed to use that lacks an MCP, such as a legacy desktop scheduler, an old ERP or a desktop accounting suite.
Read the license agreement and the vendor's terms of service. Quote the clauses that govern automation, API use and interoperability. If they forbid automation, stop here and report that.
Write authorization.md stating: the licensed user, the clauses permitting (or limiting) automation, and the legal basis you will rely on for interoperability work, such as the DMCA Section 1201(f) interoperability exception in the US and the principle that interface facts are not copyrightable.
State plainly that this work targets only software the user is licensed to operate and never defeats access controls protecting other parties' data.
If the target is a network device, confirm it is the user's own device on the user's own network.

List the top five real actions the user performs in the tool, from their actual workflow, not a feature tour.
For each action, investigate interfaces in this order and pick the first that works:
1. A documented official API.
2. The tool's own export/import file formats (read what it writes, write what it reads).
3. Its local database (for example a SQLite file) or data files, read directly.
4. Its config files.
5. UI automation, only if none of the above exists for that action.
Use gitingest, deepwiki and gitmcp to understand any open repos or SDKs you are allowed to read, following @ariacodez.
Record in actions.md the chosen tier per action and why, and count how many of the five require UI automation versus direct data access. That count is an early read on how brittle and how maintainable the wrapper will be.

Have the agent build a CLI, @catlabs-style: 'build yourself a CLI tool to interact with [the tool]', one subcommand per action.
Each subcommand uses the interop tier chosen in step 2. API-backed and file-backed subcommands should be pure data operations with no UI dependency. UI-automation subcommands are isolated in their own module so their brittleness is contained.
Make every subcommand idempotent where possible and give it a dry-run mode that shows what it would do without doing it.
Add structured logging: each invocation records the action, the tier, inputs (redacting any secret or personal data), the result and the duration.
Write unit tests that run against a sandbox copy or test account of the tool, never against live production data.
Keep tokens low by preferring the CLI's compact output over large tool schemas, as @catlabs notes.

Wrap the CLI as an MCP server, which @catlabs and @atlasberry008 note is the right layer for authentication, discovery and distribution, even though the CLI does the work.
Each action becomes an MCP tool with a typed schema and a clear description of what it does and its blast radius.
Authentication reads credentials from the environment or a secret store at call time, never hard-coded, and the server never logs credential values.
Mark write or destructive actions as requiring explicit confirmation, so an agent cannot silently mutate the user's data.
Add a capability manifest so a calling agent can discover the five actions and their constraints.
Test the server with a real agent performing one safe read action end to end.

Run each of the five actions 50 times against the sandbox, varying inputs realistically. Record the success rate per action in reliability.csv.
Expect API-backed and file-backed actions to be near-perfect and UI-automation actions to be flakier. That gap is a finding, not a nuisance.
Simulate a vendor update: change the version, or mutate the interface the brittle actions depend on (rename a UI element, shift an export column), and re-run the replay. Record which actions survive and which break.
Set a pass threshold (for example 98% success) and mark each action pass or fail.
For any action below threshold, note whether a more stable tier is available that you skipped.

Run a week of the user's real tasks through the MCP server (on their own licensed instance, with their approval).
Log every breakage: which action, what changed, how long the fix took.
Estimate the maintenance cost: breakages per week, hours per fix, and how that scales across the number of client instances a service would cover.
Tie it to @tom__shipley's Bending Spoons point: the value is in rebuilding and operating a core cheaply, so the question is whether operating this wrapper is cheap or a treadmill.
Compute the falsifier metric directly: breakages per vendor update per month. If it exceeds one, the maintenance eats the margin.
Record which actions caused the most breakage, since those are the ones to move to a more stable tier or drop.

Run the oracle pass:
(a) Per-action reliability: the 50-run success rate against the threshold.
(b) The vendor-update simulation result per action.
(c) The real-week error count through the MCP server.
(d) The legal-basis sheet, reviewed against the license and the interoperability exception.
(e) The falsifier: is breakage more than once per vendor update per month? If so, state plainly this is a consulting engagement priced hourly, not an arbitrage priced as a flat 'we run it for you' service.
Write report.md with the sections Authorization, Actions, Reliability, Maintenance, Verdict and Gaps. State which actions are robust (API/file-backed) and which are fragile (UI-backed), and whether the wrapper is worth selling as a service. Rank the gaps by impact on reliability and legal exposure.

You are an independent reviewer: an integration engineer plus someone who reads licenses. Open report.md, authorization.md, actions.md, cli/, mcp/, reliability.csv and maintenance.md.
1. First, confirm authorization: does authorization.md quote clauses permitting the automation, for licensed software? Any action lacking a legal basis is flagged and treated as not shippable.
2. Enumerate every claim (per-action reliability, update-survival, maintenance rate, interop tiers) and mark each verified, unverified or false. Recompute the reliability numbers from the 50-run logs and check they match the report.
4. Check the interop tiers: is any action using UI automation when a documented API or file format existed?
5. Confirm no write action is exposed via MCP without a confirmation gate, and no credential value appears in logs.
6. Check the falsifier metric: breakages per vendor update per month, computed from the real week plus the simulation.
7. Confirm nothing targets a third-party system or defeats an access control protecting others' data.
8. Rank the gaps by reliability and legal exposure, fix the top three, and report what you could not fix.
Return audit.md with the columns claim, status, evidence and fix, plus 'Remaining gaps' and an A-F grade on whether the wrapper is a sellable arbitrage.