Use Case
Right now nothing exposes the request runner to an AI agent as a callable tool. An agent that wants to run a request has to shell out to the command-line tool and parse its text output - there's no direct interface for it.
The AI Skill only teaches authoring: it explains how to write a valid request block but says nothing about running one or checking whether it actually worked.
Agent-written .void files are only picked up by accident - the app's general file-watcher treats an agent's write exactly like any other file change, with no verification step and no feedback loop built around it.
Results never get written back into the file itself. Running a file already produces a detailed, structured result (pass/fail, timing, response data) and can save that to a separate output file, but it never goes back into the .void file that produced it.
The core gap: an agent can generate something that looks like a valid .void file, but has no way to check whether it's actually correct or see what a real response looked like.
Proposed Solution
1. An MCP server over the runner - exposes what running requests already does today as tools an agent can call directly, instead of shelling out to a CLI and scraping text:
- Read the project: list which
.void files exist and what requests are in them.
-
- Execute a request: run a specific request (or a whole file) and get a structured result back - the same execution that happens today, just returned as data instead of console text.
-
-
- Write the result back into the file: new - today a result only goes to a separate output file; this writes it back into the
.void file it came from, so the file carries a record of what actually happened when it last ran.
This server is just an ordinary local program that stays alive and responds to calls instead of running once and exiting. It has nothing to do with the Voiden desktop app being open - it's a separate process the AI tool starts on the user's machine at the start of a session (pointed at a project folder via a config line), used for the duration of the session, and shut down afterward. Nothing runs remotely and nothing keeps running after the session ends.
2. A bidirectional AI Skill - extend it to teach the full loop, not just authoring:
- Write a request (already covered today).
-
- Execute it and read back what actually happened, using the MCP server above.
-
-
- Fix it if the result shows it's wrong.
3. First-class treatment of agent-written files - when a .void file appears or changes from outside the app, actively check it's well-formed and surface problems, the same immediate feedback a person gets while typing in the editor, instead of silently accepting whatever lands on disk.
Together: the skill teaches an agent how to write a file, the MCP server lets it execute and get a real result back, and the file-write support confirms what actually landed on disk is valid - the difference between an agent that can generate a plausible file and one that can generate, run, verify, and fix one.
Alternatives Considered
Continuing to rely on the app's general file-watcher and having agents shell out to the CLI and parse text output - this is fragile: nothing catches a mistake until someone opens the file, and there's no structured interface for an agent to use.
Examples
// Conceptual MCP tools exposed over the runner
read_project() -> { files: [...], requests: [...] }
execute_request(file, requestName) -> { pass, timing, response }
write_result(file, requestName, result) -> writes result back into the .void file
Additional Context
Executing a request means making a real HTTP/GraphQL/etc. call - potentially against real APIs with real credentials (auth tokens, API keys from the project's environment variables). Letting an agent trigger that automatically is more sensitive than letting it generate text, and should be thought through deliberately (e.g. requiring explicit confirmation before execution, or scoping which environments an agent is allowed to run against) rather than assumed safe by default.
Use Case
Right now nothing exposes the request runner to an AI agent as a callable tool. An agent that wants to run a request has to shell out to the command-line tool and parse its text output - there's no direct interface for it.
The AI Skill only teaches authoring: it explains how to write a valid request block but says nothing about running one or checking whether it actually worked.
Agent-written
.voidfiles are only picked up by accident - the app's general file-watcher treats an agent's write exactly like any other file change, with no verification step and no feedback loop built around it.Results never get written back into the file itself. Running a file already produces a detailed, structured result (pass/fail, timing, response data) and can save that to a separate output file, but it never goes back into the
.voidfile that produced it.The core gap: an agent can generate something that looks like a valid
.voidfile, but has no way to check whether it's actually correct or see what a real response looked like.Proposed Solution
1. An MCP server over the runner - exposes what running requests already does today as tools an agent can call directly, instead of shelling out to a CLI and scraping text:
.voidfiles exist and what requests are in them..voidfile it came from, so the file carries a record of what actually happened when it last ran.This server is just an ordinary local program that stays alive and responds to calls instead of running once and exiting. It has nothing to do with the Voiden desktop app being open - it's a separate process the AI tool starts on the user's machine at the start of a session (pointed at a project folder via a config line), used for the duration of the session, and shut down afterward. Nothing runs remotely and nothing keeps running after the session ends.
2. A bidirectional AI Skill - extend it to teach the full loop, not just authoring:
3. First-class treatment of agent-written files - when a
.voidfile appears or changes from outside the app, actively check it's well-formed and surface problems, the same immediate feedback a person gets while typing in the editor, instead of silently accepting whatever lands on disk.Together: the skill teaches an agent how to write a file, the MCP server lets it execute and get a real result back, and the file-write support confirms what actually landed on disk is valid - the difference between an agent that can generate a plausible file and one that can generate, run, verify, and fix one.
Alternatives Considered
Continuing to rely on the app's general file-watcher and having agents shell out to the CLI and parse text output - this is fragile: nothing catches a mistake until someone opens the file, and there's no structured interface for an agent to use.
Examples
Additional Context
Executing a request means making a real HTTP/GraphQL/etc. call - potentially against real APIs with real credentials (auth tokens, API keys from the project's environment variables). Letting an agent trigger that automatically is more sensitive than letting it generate text, and should be thought through deliberately (e.g. requiring explicit confirmation before execution, or scoping which environments an agent is allowed to run against) rather than assumed safe by default.