Recently Opened Issues / Near-Term Planned Work#

Introduction#

This page tracks the five GitHub issues opened on 2026-07-05 that represent near-term planned work for the Stringy repository. Stringy is a format-aware alternative to the standard strings command that uses binary format intelligence to surface meaningful strings where traditional tools see noise 1.

The issues fall into two themes:

• Output, Ranking, and Classification Quality — four issues targeting the correctness and usability of Stringy's core string extraction pipeline, covering bounded default output, ranking accuracy for debug/toolchain paths, Mach-O export classification precision, and plain-text format support.
• AI-Agent Integration — one issue adding an MCP (Model Context Protocol) server interface so AI agents can call Stringy programmatically.

This document is intended for maintainers and contributors planning near-term work. Each issue entry includes a problem statement, the proposed behavior, and the modules likely to be affected.

Output, Ranking, and Classification Quality#

Four issues address correctness and usability across Stringy's extraction, ranking, and classification pipeline.

Issue #202 — feat: bound default output instead of dumping every string#

→ github.com/…/issues/202

Problem#

Stringy currently emits every extracted string it finds. Because a single binary can yield hundreds or thousands of strings, unbounded default output is unwieldy and not user-friendly. The CLI entrypoint (src/main.rs) is still a stub 2 and the output module (src/output/mod.rs) is empty 3, meaning no limit or sorting is applied before strings reach the user.

The project's own concept.md already anticipates a --top 200 flag and a human-readable sorted view 4, and the FoundString data type carries a score: i32 field specifically for ranking 5. The scoring formula is defined as:

Score = SectionWeight + EncodingConfidence + SemanticBoost – NoisePenalty

6

Proposed Behavior#

Default output should be bounded — show the top-N highest-scoring strings rather than the full set. A flag such as --all (or --top N) should allow users to opt in to unbounded output. The existing score field on FoundString provides the natural ranking key once the scoring pipeline is wired up.

Affected Modules#

Issue #203 — fix: debug-info toolchain paths over-ranked as top-value strings#

→ github.com/…/issues/203

Problem#

Debug information sections and toolchain build paths (e.g., compiler installation paths embedded in DWARF data) are scoring too high and appearing near the top of results. This is a ranking-accuracy bug: even though debug sections are assigned a low base weight (Mach-O __DWARF sections receive weight 0.2 in the section classifier 7), long, syntactically structured strings such as /usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib can still accumulate enough semantic or length-related score to surface prominently.

The relevant source types are already modelled — SectionType::Debug and StringSource::DebugInfo both exist in src/types.rs 8 9 — but the ranking engine that would apply an appropriate NoisePenalty to strings from these sources has not yet been built. The classification module is currently an empty stub 10.

Proposed Behavior#

The ranking pipeline should apply a dedicated penalty or hard cap to strings whose source is StringSource::DebugInfo or whose section type is SectionType::Debug. Additionally, the classification system should recognise common toolchain path patterns (e.g., /rustlib/, /llvm/, /usr/lib/gcc/) and further deprioritise them to prevent them from floating to the top of results.

Affected Modules#

Issue #204 — bug: Export tag over-applied to ~55% of Mach-O symbol strings#

→ github.com/…/issues/204

Problem#

The Tag::Export classification 12 is being applied to approximately 55 % of all Mach-O symbol strings — far too broadly. The root cause lies in extract_exports() inside src/container/macho.rs 13, which uses the following predicate to identify exported symbols:

fn is_defined_symbol(nlist: &goblin::mach::symbols::Nlist) -> bool {
    nlist.n_sect != 0 && nlist.n_value != 0
}

14

This check — "the symbol has a section and a non-zero address" — matches every defined symbol in the binary, not just those that are publicly visible to the dynamic linker. The only additional guard is is_meaningful_symbol(), which only filters out single-character underscore symbols 15. As a result, internal static functions, local labels, and compiler-generated symbols all receive the Export tag.

Proposed Behavior#

Fix extract_exports() to use the Mach-O N_EXT flag (external visibility bit in the n_type field of an Nlist entry) to correctly identify symbols that are actually exported to the dynamic linker. Private defined symbols that lack N_EXT should not receive the Tag::Export tag. This will significantly reduce the false-positive rate and improve the signal-to-noise ratio of export-tagged strings.

Affected Modules#

Issue #205 — feat: treat plain text as a known format#

→ github.com/…/issues/205

Problem#

Plain text files are not recognised as a distinct input format. The format detector in src/container/mod.rs delegates to goblin::Object::parse() and maps any non-ELF/PE/Mach-O input to BinaryFormat::Unknown 17, which then causes create_parser() to return a StringyError::UnsupportedFormat error 18. The BinaryFormat enum currently has no variant for plain text 19.

This means passing a .txt, .log, script, or configuration file to stringy fails outright, even though extracting its strings is a perfectly sensible operation.

Proposed Behavior#

Add a BinaryFormat::PlainText variant to the BinaryFormat enum. For plain text inputs, Stringy should use a file-order passthrough strategy: emit strings in their original file order without applying score-based reordering. The ranking pipeline must be bypassed for this format — plain text lines have no binary section structure to weight, and reordering them would destroy the natural reading order that makes plain text useful.

Affected Modules#

AI-Agent Integration#

One issue targets a new integration surface that makes Stringy callable by AI agents.

Issue #201 — feat: expose stringy as an MCP server for AI agent integration#

→ github.com/…/issues/201

Problem#

AI agents need a standardised, programmatic way to invoke Stringy's functionality. Today, Stringy is delivered solely as a CLI binary 21 and a Rust library with public API exports (src/lib.rs, 22). There is no network-accessible interface, no MCP server, and no structured tool-call surface — meaning an AI agent that wants to analyse a binary must shell out to the CLI and parse unstructured output, which is fragile and lossy.

Proposed Behavior#

Add an MCP (Model Context Protocol) server interface so that AI agents can call Stringy's capabilities as first-class tool calls. The server should expose at minimum:

• analyze_binary — accept a binary file (by path or bytes) and return structured string extraction results in the FoundString schema 23.
• extract_strings — extract strings with configurable filters (minimum length, encoding, sections).
• filter_by_tag — return strings matching one or more semantic tags (e.g., url, guid, export) using the existing Tag enum 24.

The implementation should live in a new src/mcp/ module (or as a separate binary crate) and build on the existing public library API. The library's format detection, parsing, extraction, and classification pipeline is the authoritative implementation; the MCP server is a thin transport layer on top of it.

Affected Modules#

Summary#

The five issues opened on 2026-07-05 fall into two clear focus areas for Stringy's near-term roadmap:

1. Output, ranking, and classification quality — Issues #202, #203, #204, and #205 collectively address the gap between Stringy's well-designed scoring and classification data model 27 and the implementation of those components. The src/output/mod.rs and src/classification/mod.rs modules are currently empty stubs 28 29; these issues define the concrete behaviours that should drive their implementation.

2. AI-agent integration — Issue #201 opens the door to a new consumer class by wrapping Stringy's library in a Model Context Protocol server, making its binary-analysis capabilities available to AI agents without requiring brittle CLI scraping.

Contributors looking to make an immediate impact are encouraged to explore any of these issues. The ranking and output issues (#202, #203) are good entry points for anyone already familiar with the FoundString scoring model 23 and concept.md 30. The Mach-O export bug (#204) is well-scoped and self-contained in src/container/macho.rs 31. The plain text format issue (#205) requires touching the format-detection boundary (src/container/mod.rs, 32) but is likewise narrowly bounded. The MCP server issue (#201) is the largest net-new effort and is best tackled after the core extraction pipeline is stabilised.

Visit the Stringy issue tracker to claim or discuss any of these items.