Components

Implemented MCPs

A few MCP servers are implemented and documented:

• Echo server: a small stdio MCP example. See the echo server guide.
• Local workspace MCP: a bundled stdio server for worktree-aware file and shell tools. Shell commands are not sandboxed. See the local workspace tool guide.
• run_js gateway: bounded JavaScript composition of downstream MCP tools. See the gateway guide.
• Decision API MCP: typed noul, choice, and score evaluations for SystemOne models such as Jev from TypeSafe; OpenRouter is the default backend. See the Decision API guide.

Agent entry points

Build both interfaces:

bazel build //:std_slop //:sl

After model authentication and configuration, start the terminal UI or run a scripted prompt:

bazel-bin/app/std_slop
bazel-bin/app/sl --prompt "Summarize the repository structure"

Use the walkthrough for interactive sessions and the sl guide for scripts. Batch mode, configuration, and workflow details follow below.

Library quick starts

Build the MCP client examples:

bazel build //mcp/client:list_tools_example //mcp/client:call_tool_example

See the client guide for HTTP authorization, modern stdio connections, and argv configuration.

Build and test the stdio echo server:

bazel build //mcp/server:echo_server
bazel test //mcp/server:echo_server_test

See the server guide for requests, framing limits, and tool registration.

Build the Markdown parser and terminal renderer:

bazel build //markdown:parser //markdown:renderer

See the Markdown guide for parser and terminal renderer APIs.

Component boundaries

• The Markdown library and echo server do not need a model, API key, or agent database. The echo integration test needs Python 3.
• MCP clients support Streamable HTTP and modern MCP 2026-07-28 over local stdio. The inbound server package supports stdio only. Agent runtimes start enabled stdio commands as child processes; they do not use an HTTP wrapper or background daemon.
• The server does not automatically expose agent tools. Applications must register tools and enforce their own access policy.
• SQLite sessions, model authentication, personas, and mail workflows belong to the coding-agent runtime. They are not requirements for every library.
• The Markdown renderer produces terminal output with ANSI styling. It is not an HTML renderer.

Build and test

Use a C++17 compiler and Bazel (Bazelisk is recommended). Build and test the monorepo:

bazel build //...
bazel test //...

The library quick starts above build selected components. Model credentials are needed for live agent/model calls, not for the library builds or local echo test.

Code conventions

• C++ Standard: C++17.
• Style: Google C++ Style Guide.
• Exceptions: Disabled (-fno-exceptions).
• Memory: RAII and std::unique_ptr exclusively.
• Error Handling: absl::Status and absl::StatusOr.
• Changes must remain ASan- and TSan-clean.

Documentation

• std::slop Coding Agent: Interactive setup, configuration, and first sessions.
• sl Command-line Tool: Scripted prompts, state commands, and MCP configuration.
• MCP Client API: C++ HTTP client, bearer tokens, and OAuth helpers.
• MCP Server API: Stdio server, inline echo example, limits, and security scope.
• Agent Database and Schema: The SQLite-backed agent runtime and its data model.
• Markdown: Parser and terminal renderer APIs and examples.

• Personas & Skills: Understanding global context injection and modular skills.
• Documentation Guide: Entry point and reading order for the documentation set.
• Sessions: How context isolation and management work.
• Context Management: The history and strategy for managing model memory.
• MCP User Guide: How std_slop registers, authenticates, discovers, and exposes MCP tools.
• Subquery Implementation Notes: Design and policy notes for INI-configured llm_query specializations.
• Fuzzing: FuzzTest targets, invariants, and how to run/extend the fuzz suite.
• Contributing: Code style, formatting, and linting guidelines.

Repository layout

Agent runtime modules

The shared agent runtime includes:

• database.h: Manages the SQLite-backed ledger. Handles persistence for messages, tools, skills, sessions, and usage data.
• tool_dispatcher.h: Implements a thread-safe execution engine. It dispatches multiple tool calls concurrently while ensuring results are returned in the proper order for the LLM.
• cancellation.h: Provides a mechanism for interrupting tasks. It supports registering callbacks to kill shell processes or abort HTTP requests.
• orchestrator.h: high-level interface for model interaction. The Responses API orchestrator manages history windowing and response parsing.
• shell_util.h: Executes shell commands in a separate process group, with support for live output polling and termination on cancellation.
• http_client.h: A cancellation-aware HTTP client used for model API calls.

Agent interface and display

• interface/: Implements the terminal UI with readline input, ANSI colors, and terminal control sequences.
• markdown/: Uses Tree-sitter for Markdown parsing and code highlighting (C++, Python, Go, JavaScript, Rust, Bash). The agent UI uses it to render responses; C++ callers can use the library separately.
• app/main.cpp: The primary event loop. Coordinates between the Orchestrator, ToolDispatcher, and UI.