Crate scrybe_tools 

Scrybe tools — one ToolSpec registry shared by the CLI and the MCP server.

Foundation crate for the MCP rebuild (issue #122; design docs/design/mcp-rebuild.md). A single Registry is consumed by both front ends, so CLI↔MCP parity holds by construction: same handler, different envelope. This first slice is deliberately additive — the core types, the Registry, the headless Transport, and the pure render tool. Dispatch-through-scrybe-rpc, the remaining tools, and the protocol fixes land in later phases (design §8).

Re-exports

pub use figures::export_figures;

pub use figures::plan_figures;

pub use figures::FigurePlan;

pub use figures::FigureResult;

Modules

autolaunch

Opt-in auto-launch of the Scrybe desktop app (issue #225).

figures

Export every Mermaid diagram in a document to sibling PNG figures.

lint

Document linter — walks the AST and produces a LintReport.

schema

The shared JSON-Schema envelope for every tool’s data payload (A4).

tools

Built-in tool groups. Each module contributes one or more crate::ToolSpecs via a spec() (or specs()) constructor; [register_defaults] wires them into the crate::Registry. Feature-gated groups (vcs, swarm) will be added here behind #[cfg(feature = ...)] in later phases.

Structs

Ctx

Handler execution context — carries the transport a stateful tool would use.

DataSchema

Versioned schema for a tool’s stable data payload. Agents read data; they never parse description prose or the human text (design §4A).

Headless

No socket: only the pure, GUI-free subset of tools runs. GUI/stateful tools get a clean NoApp.

LiveApp

Dials the live app over ~/.scrybe/sock via scrybe-rpc’s client — the same wire the CLI uses, so a tool routed through this transport drives the running editor exactly like scrybe <cmd> does. When no app is running, call returns NoApp and pure tools should fall back to Headless.

Registry

The shared tool registry consumed by both front ends.

ToolError

A business-level failure: the tool ran and said “no” (e.g. “heading not found”). This is DATA carried inside the outcome, not an engine fault. Each surface decides its own presentation: the MCP adapter reports a failed invocation (isError: true with the {code, message} in structuredContent — A4); the CLI prints the error and keeps its exit semantics.

ToolOutcome

The result of a successful tool invocation. A Some(tool_error) still means the call succeeded — the tool told the agent “no”. Engine faults are the separate EngineFault type returned by the dispatcher.

ToolSpec

One tool, shared verbatim by the CLI and the MCP server (design §2.2).

Enums

EngineFault

Engine fault: the dispatcher could not even run the tool (unknown tool, bad arguments, transport down). Surfaces as a non-zero CLI exit; on MCP, UnknownTool is a JSON-RPC -32602 protocol error and the rest are isError: true results (A4 mapping in scrybe-mcp-server/src/server.rs). Distinct from a business ToolError carried inside the outcome (design §2.2, §5).

Facet

Tool group — drives progressive disclosure and feature gating (design §4).

TransportError

Failure talking to the live app over the socket, in three semantic classes that mirror scrybe_rpc::ClientError’s taxonomy.

Traits

Transport

Round-trips scrybe-rpc requests to the live app (design §2.3). The only place a tool touches the outside world — the future LiveApp transport and the modulex extraction seam both live behind this trait.