Firedrill operator MCP
OfficialClick on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Firedrill operator MCPdiscover schemas and preview a small simulation recipe for checkout"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Firedrill operator MCP
Operate Firedrill from a coding agent: discover schemas, prepare simulations, inspect retained evidence, compare runs and manage authorized synthetic Tools. This is the operator → Firedrill connection on the human's behalf. It does not sign in to the coding-agent provider or the application being simulated.
This repository contains a standalone stdio client, its TypeScript source and its exact client dependencies. It contains no Firedrill engine, service, database or HTTP server. Customer applications execute in their own runner; MCP admission alone never launches code on a laptop.
Install the client
Use Node 22 or newer. From your application repository:
npm install --save-dev --save-exact --ignore-scripts @firedrill-run/mcp@2.0.0The CLI package also includes the same firedrill-mcp binary: install one owner
of that binary per application, not both packages.
In a host that supports stdio MCP, configure command npx, arguments
["--no-install", "firedrill-mcp"] and the application's working directory.
Production is automatic; no API-address environment variable is needed.
If the host cannot set a working directory, use the absolute installed binary
path instead. Alternate API addresses are rejected. Do not put a credential in the config.
The client reuses the protected Firedrill login for that exact origin. Otherwise
firedrill_authenticate starts an explicit device approval: show the human its
URL/code, observe status, and select an authorized organization with choose
only when needed. Tokens are not returned to the model. External verification,
invitation or administrator actions must be completed by the human; they cannot
be bypassed by creating another organization. A later account/organization
change requires an explicit reconnect, not silently switched authority.
For CI, supply an authorized scoped FIREDRILL_TOKEN through the environment
from your secret store. It takes precedence over saved login; CI never prompts
or opens a browser. FIREDRILL_MCP_READONLY=true removes mutation tools while
the API still checks current authority on every request.
Related MCP server: flameox
First useful workflow
Read
firedrill_discover, then the advertisedfiredrill_schemadefinitions.Read
firedrill_contextand deliberately choose the project/environment.Inspect the application's real command, HTTP or native invocation seam. Preview a small authored recipe before admitting it. Checks and Tools are optional; evaluation is a separate explicit choice.
If authorized to execute, preserve the creation key and exact arguments. Follow the returned continuation through the CLI or native SDK to attach a customer-owned runner to that same batch. Do not create a second batch.
Read reports/evidence using exact scope and returned cursors. Keep execution, outcome, assessment and CI gate separate; missing evidence is not zero.
Mutations require saved idempotency keys. After an uncertain reply, reconcile the same action/key; never repeat a target merely to recover its evidence. Synthetic Tool grants are separate, short-lived target credentials. Never copy operator tokens into target input or model context. Native/ordinary command execution is not a sandbox, and Tool rewind does not reset the external app.
The companion firedrill-skills repository supplies optional task-oriented
instructions. Installing instructions is not permission to run a simulation,
upload customer source, change workspace trust or authorize another account.
Build this source export
npm install --ignore-scripts
npm run buildThe explicit build compiles src/mcp/main.ts and its local client-only closure
into dist/. The binary starts dist/mcp/main.js. No private checkout,
workspace alias, global installation or automatic lifecycle build is needed.
package.json pins runtime and build dependencies; PACKAGING.json records the
reviewed artifact's source/file hashes and original dependency notices. A local
rebuild is a new artifact, not automatically the reviewed release.
server.json describes the npm transport and version for the official MCP
Registry. Directory availability is independent of installing the client directly.
License
The client is proprietary under the client use permission.
Third-party code retains its own notices under notices/ and bundled package
licenses. A readable source export does not make the private service open-source.
Available Tools
1 toolfiredrill_authenticateA
Authorize the coding-agent operator to use Firedrill on the human's behalf using WorkOS device approval. Shares the CLI's protected login; never returns tokens. Does not authenticate the coding-agent provider or the target application. status reads progress; start explicitly initiates approval or resumes the same protected sign-in after external action; choose selects a legal organization choice; cancel stops this local wait without discarding protected state. Do not start in CI.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations (openWorld, non-readonly, non-idempotent): it discloses the WorkOS device-approval mechanism, that it shares the CLI's protected login, that it never returns tokens, and that cancel preserves protected state. The remaining gap is that the return/polling shape of 'status' and the device-code hand-off are not described, which matters for an open-world auth flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose before the action breakdown, and every sentence carries information (scope limits, security behavior, per-action meaning, CI constraint). The semicolon-joined action list is dense but readable; only marginal trimming is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action auth flow with no output schema and no sibling tools, the description covers purpose, mechanism, per-action behavior, state semantics, and a deployment constraint. It is complete enough to invoke correctly, though the expected result of each action (e.g., what 'status' reports, what the human must do externally) is not spelled out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is reported high, so the baseline is 3, but the description genuinely enriches the enum values by explaining the behavioral intent of status/start/choose/cancel rather than just naming them. It does not, however, explain the 'reauthorize' or 'retryRefresh' flags on 'start', which remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and object ('Authorize the coding-agent operator to use Firedrill') and names the mechanism (WorkOS device approval). It further delimits scope by saying what it does NOT authenticate (the provider, the target application), so an agent can tell exactly what outcome this tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives per-action usage: 'status reads progress', 'start explicitly initiates approval or resumes...', 'choose selects a legal organization choice', 'cancel stops this local wait'. It also adds an explicit exclusion ('Do not start in CI'), so both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v2.0.0- First observed
firedrill_authenticate
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusing it with another tool. The tool's internal multi-mode nature (start/status/choose/cancel) affects parameter selection, not tool selection, so disambiguation across the set is trivially perfect.
The single tool name 'firedrill_authenticate' follows a clear snake_case verb_noun convention. With only one tool, there is no inconsistency to penalize.
A single tool is borderline thin for an MCP server, even if authentication is the primary purpose. The server is named 'Firedrill operator MCP', suggesting a broader operator scope that one tool cannot reasonably cover.
The surface covers only the authentication flow (start/status/choose/cancel) and lacks any logout, refresh, or actual operator actions implied by the server name. For an 'operator' server, this is a significant gap that would leave agents unable to perform most domain tasks.
Maintenance
Related MCP Connectors
Persistent memory, hybrid search and a goal graph for AI agents, over stdio or remote HTTP.
- naturaliOAuthai.naturali
Configure AI agents, give them knowledge and tools, and read back every generation they run.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Machine-native research commons for agent evidence, discovery, rooms, and bounded research quests.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides a stdio MCP bridge for coding agents to query and record engineering knowledge locally, preserving debugging history, failed attempts, and verified solutions.0MIT
- AlicenseCqualityAmaintenanceEnables coding agents to query, compare, and audit local profiler traces, benchmarks, memory captures, and execution evidence without uploading code or data, using CLI and MCP interfaces.111377 PyPI210MIT
- AlicenseNot gradedqualityAmaintenanceEnables local AI agents to work with SQL workspaces and databases by inspecting schemas, running bounded queries, and managing recoverable imports, previews, applies, diffs, and undos over stdio.1MIT
- AlicenseNot gradedqualityAmaintenanceEnables compatible agents to call registered local tools and read resources through one stdio server, including harness preparation, knowledge search and document management, memory retention/recall, correction proposals, advisory decisions, tool/skill discovery, and log/source inspection.2Apache 2.0