Problem statement
AI coding agents and LLM tooling (Claude Code, Cursor, etc.) increasingly consume tools through the Model Context Protocol (MCP), which gives them typed tool discovery and structured request/response schemas over a standard transport. Today the only way for an agent to use Stringy is to shell out to the CLI and parse --json output as free-form text: there is no schema, no capability discovery, and every caller re-implements argument construction and result parsing. For a binary-analysis tool whose whole value is structured, classified strings, that is a poor fit -- Stringy's output is exactly the kind of structured data an agent wants to call directly.
Proposed solution
Expose Stringy as an MCP server that wraps the existing extraction + classification pipeline as first-class MCP tools.
The library is already well-positioned for this: main.rs is a thin wrapper that builds a PipelineConfig and calls Pipeline::run(&path), and the JSON output formatter already emits structured results. An MCP server would reuse the same Pipeline, PipelineConfig, FilterConfig, and JSON formatter rather than duplicating logic.
Sketch:
- Entry point: a
stringy mcp subcommand (or a separate stringy-mcp binary), gated behind an optional mcp Cargo feature so the default CLI build stays lean.
- Transport: stdio first (the standard for local agent integrations); leave SSE/HTTP as a later enhancement.
- Tools to expose (mapping existing CLI flags to typed tool parameters):
extract_strings -- input: file path (and/or raw bytes), plus the existing knobs (min_len, top, only_tags, no_tags, enc, raw); output: the classified strings as structured JSON (reuse the output/json formatter).analyze_binary -- input: file path; output: container/format metadata plus the top-N ranked strings (a summary-style call).
- Modules touched: new
mcp/ module or bin (server scaffolding, tool schemas, request -> PipelineConfig mapping); reuse pipeline, output (json), and types. No changes needed to container/extraction/classification internals.
Constraints to respect:
- Must remain compatible with
#![forbid(unsafe_code)] (verify the chosen SDK builds under it).
- MSRV 1.91, Edition 2024.
- Prefer the official Rust MCP SDK (
rmcp) over hand-rolling the protocol.
- Validate/sanitize the incoming file path at the tool boundary (path traversal, existence, permissions) and surface Stringy's typed errors (
StringyError) as structured MCP errors.
This is epic-sized and should be split into tasks (SDK spike + feature flag, server scaffolding + stdio transport, per-tool schemas + config mapping, error mapping, integration tests, docs). Open here to agree on scope before any PR, per CONTRIBUTING.md.
Alternatives considered
- Keep CLI +
--json, let agents shell out. Works today, but no schema, no tool discovery, no streaming; every caller re-parses text and reconstructs flags. Higher friction and more brittle.
- Expose an HTTP/REST server instead. Heavier surface (auth, CORS/CSP, network exposure) and less aligned with local agent tooling, which overwhelmingly uses MCP over stdio.
- Ship the MCP server as a separate wrapper repo. Duplicates the config/flag surface and drifts from the core as flags change; keeping it in-tree (behind a feature flag) reuses
PipelineConfig directly.
Open questions
- Subcommand (
stringy mcp) vs. separate binary (stringy-mcp)?
- Accept raw bytes in-request, or path-only (given the pipeline currently requires a file path and
main.rs bridges stdin via a tempfile)?
- Which tools are in the MVP -- just
extract_strings, or also a metadata/summary tool?
Area
Pipeline / CLI
Problem statement
AI coding agents and LLM tooling (Claude Code, Cursor, etc.) increasingly consume tools through the Model Context Protocol (MCP), which gives them typed tool discovery and structured request/response schemas over a standard transport. Today the only way for an agent to use Stringy is to shell out to the CLI and parse
--jsonoutput as free-form text: there is no schema, no capability discovery, and every caller re-implements argument construction and result parsing. For a binary-analysis tool whose whole value is structured, classified strings, that is a poor fit -- Stringy's output is exactly the kind of structured data an agent wants to call directly.Proposed solution
Expose Stringy as an MCP server that wraps the existing extraction + classification pipeline as first-class MCP tools.
The library is already well-positioned for this:
main.rsis a thin wrapper that builds aPipelineConfigand callsPipeline::run(&path), and the JSON output formatter already emits structured results. An MCP server would reuse the samePipeline,PipelineConfig,FilterConfig, and JSON formatter rather than duplicating logic.Sketch:
stringy mcpsubcommand (or a separatestringy-mcpbinary), gated behind an optionalmcpCargo feature so the default CLI build stays lean.extract_strings-- input: file path (and/or raw bytes), plus the existing knobs (min_len,top,only_tags,no_tags,enc,raw); output: the classified strings as structured JSON (reuse theoutput/jsonformatter).analyze_binary-- input: file path; output: container/format metadata plus the top-N ranked strings (a summary-style call).mcp/module or bin (server scaffolding, tool schemas, request ->PipelineConfigmapping); reusepipeline,output(json), andtypes. No changes needed to container/extraction/classification internals.Constraints to respect:
#.rmcp) over hand-rolling the protocol.StringyError) as structured MCP errors.This is epic-sized and should be split into tasks (SDK spike + feature flag, server scaffolding + stdio transport, per-tool schemas + config mapping, error mapping, integration tests, docs). Open here to agree on scope before any PR, per CONTRIBUTING.md.
Alternatives considered
--json, let agents shell out. Works today, but no schema, no tool discovery, no streaming; every caller re-parses text and reconstructs flags. Higher friction and more brittle.PipelineConfigdirectly.Open questions
stringy mcp) vs. separate binary (stringy-mcp)?main.rsbridges stdin via a tempfile)?extract_strings, or also a metadata/summary tool?Area
Pipeline / CLI