droid-mcp

droid_send

Send a prompt into a Factory Droid session and apply model, autonomy, or tool settings before it runs, interrupting the current turn when mode is 'interrupt'.

Instructions

Send a message into a session as the user. Sessions this server started take it directly; others need FACTORY_API_KEY (REST) or, for idle standalone local sessions only, allowLocalResume. mode 'interrupt' stops the running turn first. Settings and autonomy change the session before this prompt; settings a route cannot apply come back in ignored. Pick a model with droid_models: a built-in id (claude-opus-5-5), a BYOK custom id from ~/.factory/settings.json (custom::), a tier alias (anthropic-latest-premium) or a version wildcard (claude-opus-*). reasoningEffort must be one the model supports. mission needs autonomy 'high'. Unknown models and invalid combinations are refused before anything runs.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session": "<session>",
      "prompt": "<prompt>",
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "droid_send"
  }
}

Input Schema

Name	Required	Description
`fork`	No	Fork this session id instead of starting fresh (start only)
`mode`	No
`tags`	No	Tag names to add to the session
`model`	No	Model id from droid_models
`prompt`	Yes
`mission`	No	Switch to mission mode (multi-agent); needs autonomy "high"
`session`	Yes
`useSpec`	No	Switch to spec mode: plan before editing
`addTools`	No	Add these tool ids or selectors
`autonomy`	No
`worktree`	No	Start in a git worktree; a string names the branch (start only)
`onlyTools`	No	Use only these tool ids or MCP:<server>[/<tool>] selectors
`specModel`	No	Model for spec mode (defaults to model)
`removeTools`	No	Remove these tool ids or selectors
`workerModel`	No	Mission worker model (needs mission)
`idempotencyKey`	Yes
`validatorModel`	No	Mission validator model (needs mission)
`reasoningEffort`	No	Must be one the model supports
`allowLocalResume`	No
`appendSystemPrompt`	No	Text appended to the system prompt (start only)
`specReasoningEffort`	No
`workerReasoningEffort`	No
`validatorReasoningEffort`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: auth requirements per session type, that 'interrupt' halts the running turn, that settings/autonomy are applied before the prompt with unapplicable ones surfaced in `ignored`, and that invalid models or combinations are refused before anything runs. It still says nothing about what the call returns or whether it blocks until the turn completes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, then auth, mode, settings, model choice, and validation follow in a logical order with no wasted sentences. The density is justified by the 23-parameter surface; only 'reasoningEffort must be one the model supports' mildly restates the schema.

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 23-parameter mutation tool with no annotations and no output schema, the description covers the decisive risks: routing/auth, interrupt semantics, pre-prompt setting application, the `ignored` feedback channel, and pre-flight refusal. It is not fully complete because return behavior and the tool-set manipulation parameters are unaddressed.

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 61%, and the description adds real meaning beyond it for the highest-risk parameters: the four accepted model id forms (built-in, BYOK custom, tier alias, wildcard), the constraint that reasoningEffort must be model-supported, and that mission requires autonomy 'high'. It leaves the tool-selection and mode parameters (addTools/onlyTools/removeTools, fork, worktree, spec/worker/validator models) to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource ('Send a message into a session as the user') and immediately distinguishes sessions this server started from external ones. It stops short of explicitly naming the sibling that handles adjacent flows (e.g. droid_respond for permission replies), so differentiation is implied rather than complete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete conditional guidance: sessions this server started take the message directly, others require FACTORY_API_KEY (REST), and allowLocalResume applies only to idle standalone local sessions. It also explains when to use mode 'interrupt' (to stop the running turn first). It does not state when to prefer droid_start or droid_respond instead, which is the main gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server