Skip to main content
Glama
Sign In
Firedrill operator MCP

Firedrill operator MCP

Official
by firedrill-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

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.

Connect directly

Use Firedrill's remote Streamable HTTP endpoint:

https://mcp.firedrill.run/mcp

No local MCP package, Firedrill CLI or Node.js installation is required for this connection. Configure it through your host's native commands. For Codex:

codex mcp add firedrill --url https://mcp.firedrill.run/mcp
codex mcp login firedrill

For Claude Code project scope:

claude mcp add --scope project --transport http firedrill https://mcp.firedrill.run/mcp
claude mcp login firedrill

Codex writes user-wide MCP settings. Claude uses the selected project's .mcp.json and asks for project approval. In Cursor, add "firedrill": { "url": "https://mcp.firedrill.run/mcp" } under mcpServers in .cursor/mcp.json and use its browser sign-in. In Kimi Code, use /mcp-config to add a project HTTP server at that URL, then /mcp-config login firedrill. Preserve other servers. Skills/plugin installation is a separate native action.

For one-click setup links and host-specific instructions, open Connect your agent.

The browser authorization uses WorkOS. Review the identity and intended organization, and let the host store its OAuth credential privately. Do not paste tokens into chat or repository configuration. Account creation, email verification, invitations and host trust remain explicit human steps when required; never bypass them with another identity or replacement organization.

Remote MCP can prepare work and read retained results; it cannot execute a repo on the customer's machine. Actual target execution uses a separately authorized customer-owned CLI/SDK runner. CLI sign-in is separate from the MCP host's OAuth session. CI supplies its own scoped credential through a secret store and never opens browser approval. Do not transfer credentials between these clients.

Related MCP server: SwarmMojo MCP Server

First useful workflow

  1. Read firedrill_discover, then the advertised firedrill_schema definitions.

  2. Read firedrill_context and deliberately choose the project/environment.

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

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

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

Repository contents

server.json describes the remote Streamable HTTP endpoint for the official MCP Registry. Connecting uses that endpoint, not an npm MCP installation. Registry metadata does not deploy a server or prove that browser authorization works.

Previously distributed client source, exact dependency records and their license notices remain in this repository. They contain no Firedrill engine, service, database or managed HTTP server. Their presence is not an onboarding step, and local environment settings do not configure the managed remote connection.

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 tool
firedrill_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.

NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev2.0.0
    • First observedfiredrill_authenticate
Deploy Server
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

A4.3/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

The single tool name 'firedrill_authenticate' follows a clear snake_case verb_noun convention. With only one tool, there is no inconsistency to penalize.

Tool Count3/5

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.

Completeness2/5

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

ActivityMaintained
ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Related MCP Servers

  • Basalt MCP Server

    yoshiii-xyz
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables 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.
    1
    MIT

  • SwarmMojo MCP Server

    Buzburg
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables 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.
    2
    Apache 2.0

  • flameox

    siripornjames148
    F
    license
    Not graded
    quality
    A
    maintenance
    Enables coding agents to invoke profilers, benchmark tools, trace processors, and direct local commands against explicit artifact paths or argv, returning bounded typed evidence with execution provenance, coverage, and limitations. It exposes named analysis and capture tools over stdio with optional durable preservation of evidence bundles.
    -
  • SimArch MCP Server

    SimArch MCP Serverofficial

    isiraglobal
    A
    license
    B
    quality
    B
    maintenance
    Enables AI tools and agents to form contract-bound organizations, execute persistent task DAGs with independent audits, score decisions with counterfactual trees, run time-compressed world simulations, and control an on-demand localhost dashboard via stdio tools.
    6
    1
    Apache 2.0