Pi Tool Display
Keep Pi tool output compact and make file edits easier to inspect with readable diffs.
- Source repo
- MasuRii/pi-tool-display
- Stars
- ★ 304
- Last updated
- 4mo ago
- License
- MIT
- Primary language
- TypeScript
- FA score
- 60/100 · Some gaps
At a glance
- How it runs
- Works with
- Platform-specific
- Cost
- Free, no paid service needed
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- Pi users who run read or search tools often and want verbose results collapsed by default.
- Not a fit if
- Teams using a coding agent other than Pi
- Users who need a standalone interface outside the terminal
- Source review
- 60/100 · Some gaps
What does this agent do, and when should you use it?
pi-tool-display is an extension for the Pi coding agent that takes over rendering for selected built-in tools and explicitly configured custom tools. It gives read, grep, find, ls, bash, edit, and write compact output modes, including hidden results, summaries, and previews. Its edit and write diff renderer chooses split or unified layouts based on terminal width and can show pending previews while calls stream. The extension also provides MCP output modes, thinking labels, a native user message box, and /tool-display settings commands. It can be installed from a local extension directory, npm, or Git, and runs inside Pi’s terminal UI rather than as a standalone application.
Once loaded, the extension registers configurable renderers for read, grep, find, ls, bash, edit, and write, displaying results as hidden output, summaries, or limited-line previews; bash also has an opencode collapsed mode. MCP output can be hidden, summarized, or previewed, while other extension tools require explicit entries in customToolOverrides with a generic or mcp kind. edit and write share a diff renderer with auto, split, and unified layouts; during streamed arguments it can also show pending diffs scoped to the active workspace. It labels thinking blocks during streaming and in final messages, then removes those presentation labels from stored context before the next model turn. Users can open settings with /tool-display or inspect and change configuration with /tool-display show, reset, and preset commands.
- Pi users who run read or search tools often and want verbose results collapsed by default.
- Developers editing files with edit or write who want to inspect diffs and pending previews before expanding results.
- Pi users with MCP tools who want to control how much result text appears in the terminal.
- Teams using multiple Pi extensions that need per-tool ownership switches to reduce renderer conflicts.
- Extension authors who want to decorate their tools through the
pi-tool-display/tool-display-api-consumeradapter.
How do you install or deploy this agent?
Install and run the Pi coding agent, then choose one of the documented extension installation methods.
Install from npm:
pi install npm:pi-tool-displayInstall from Git:
pi install git:github.com/MasuRii/pi-tool-displayFor a local checkout, place the folder in one of Pi’s auto-discovery locations:
~/.pi/agent/extensions/pi-tool-display
.pi/extensions/pi-tool-displayHow do you use this agent?
Open the settings modal in Pi:
/tool-displayShow the effective configuration:
/tool-display showApply the default compact preset:
/tool-display preset opencodeExtensions can opt into the adapter API with this import:
import { decorateToolForDisplay, decorateMcpToolForDisplay } from "pi-tool-display/tool-display-api-consumer";For example, configure an MCP-style custom tool in config.json:
{
"customToolOverrides": {
"custom_mcp_gateway": {
"enabled": true,
"kind": "mcp",
"outputMode": "preview"
}
}
}What are this agent's strengths and limitations?
- Separate compact modes cover read, search, bash, and file editing, with results available as hidden output, summaries, or previews.
- The diff renderer supports split and unified layouts, narrow-terminal clamping, and pending previews for streamed edit/write calls.
- Built-in ownership flags and explicit custom-tool rules help it coexist with other rendering extensions.
- The README documents local-folder, npm, and Git installation paths.
- It depends on the Pi coding agent extension mechanism and is not a standalone terminal viewer.
- The README documents no support for other coding agents, so moving to another runtime would require adaptation.
- Non-built-in tools keep their original renderer by default; overriding them requires an exact tool name and, when already registered, a reload.
- The README does not specify a Node.js version or other concrete runtime dependencies.
How does this agent compare with similar options?
The README describes OpenCode-style tool rendering for Pi and refers to Pi’s built-in tools and other renderer extensions, but provides no feature or performance comparison data.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Pi Tool Display This agent | 60 · Some gaps | Agent plugin / skillFree | ★ 304 | 4mo ago | TypeScript | — |
| MiniCode | 50 · Major gaps | CLIFree + model costs | ★ 1.2k | 27d ago | TypeScript | Claude API |
| Kun Workspace | 49 · Major gaps | Desktop appFree + model costs | ★ 6.4k | 4d ago | TypeScript | ChatGPT · Codex · OpenAI API · Claude API |
| Pi Agent Harness | 42 · Major gaps | CLIFree + model costs | ★ 120k | today | TypeScript | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The evidence describes an extension focused on tool-output rendering, with per-tool ownership switches, explicit opt-in custom rules, debug logging disabled by default, and workspace-scoped reads for pending previews. This supports 2 for least privilege and data-flow transparency. The README says output can be hidden, collapsed, or truncated, but does not fully explain sensitive-output retention, exposure, or recovery semantics, so sensitive-data handling scores 1. Rendering settings do not require confirmation; only some override behavior is explicitly opted into, so user confirmation scores 1. Dependency overrides and a postinstall script are declared, but no dependency-risk audit evidence is supplied, so dependency security scores 1. No network or other external effects are shown, earning 2; reload cleanup is documented, earning 2 for rollback. An author field exists, but publisher identity is unverified and provenance evidence is limited, so source attribution scores 1.
The README, configuration example, and test-file listing broadly align on the main features and settings, earning 2 for self-consistency. Tests are supplied only as static material, and this review cannot confirm a lockfile or successful dependency installation, so dependency availability scores 1. There are troubleshooting steps for configuration, tool detection, and custom rendering, but runtime error presentation and fallback behavior are only lightly described, so failure messages score 1.
The README targets compact tool output and diff display in the Pi coding agent, with three presets, multiple output modes, and width-aware behavior; audience and scenarios score 3. MCP/RTK capability detection and custom override boundaries are described, but some MCP detection relies on names or parameter heuristics, so capability boundaries score 2. Built-in tools have fixed ownership settings and custom tools require explicit configuration, earning 2 for trigger precision. The docs state macOS, Linux, Windows, and Node 20+ support, and explain Pi install paths and capability detection, but this review has no cross-environment evidence, so environment fit scores 2.
The README is organized by feature, installation, usage, configuration, troubleshooting, and project structure, with tables and examples; information architecture and examples/FAQ score 3. It describes local, npm, and Git installation, but omits some prerequisites, so install notes score 2. Package, export, and configuration names are reasonably clear, though descriptions of the default preset and configured output defaults may confuse readers, so naming stability scores 2. Some boundaries and capability behavior are documented, but there is no systematic known-limitations section, so that criterion scores 1. The MIT license text is complete and matches the metadata, earning 3. A package version is present, but no CHANGELOG content is included in the supplied material, so versioning/changelog scores 1. The README documents cleanup and configuration paths and the package has an author field, but maintenance responsibility and an explicit support/update path are not established, so maintenance responsibility scores 1.
The feature description, presets, truncation hints, summary modes, and diff layouts support more readable verbose tool output, earning 3 for output usability. The extension offers a unified compact view across several tools and an adapter API, giving it incremental value, so marginal value scores 2. Cost-benefit discussion is mainly feature claims, without installation, performance, or usage-cost evidence, so cost-benefit scores 2.
Many README claims map to listed source areas and test filenames, but full implementation source is not supplied for line-by-line review, so claim traceability scores 2. README, package metadata, license, and test files provide limited corroboration, but the lack of full code and changelog restricts cross-source corroboration to 1. The docs distinguish configuration defaults, behavior, and capability detection to some extent; several claimed outcomes remain unverified in this static review, so fact/inference separation scores 2.
- This assessment uses only the files supplied in the prompt and did not execute code or tests; README behavior and compatibility claims are not independently verified here.
- Hidden or truncated output can conceal details a user needs to inspect; choose a mode that fits the workflow and confirm how to expand results.
- package.json declares a postinstall script and dependency overrides; the supplied materials do not include the script target or a dependency security analysis, so inspect the published contents before installation.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
[0.5.0] - 2026-07-03 Added - Added an enabled config toggle that gates tool override registration, with reload cleanup that disposes overrides and patches on session_shutdown. ([c78163d](https://github.com/MasuRii/pi-tool-display/commit/c78163dddc0f94b7a542d2d1e01109c903bc70cc)) - Added regression coverage for the active backlog: expanded large-diff rendering in constrained tmux-style panes (#23) and the esbuild lockfile bump from PR #24. ([7e46231](https://github.com/MasuRii/pi-tool-display/commit/7e4623191583f31a056602d8a08f1a4a7accd8b6)) Changed …View on GitHub ↗ -
Release notes excerpt
### Added - Added customToolOverrides for explicit opt-in rendering of non-built-in extension tools, with generic as the default kind and optional mcp rendering for MCP proxy-style arguments. - Added custom tool override coverage for malformed config, output modes, late tool registration, argument shapes, and runtime contract preservation. Changed - Preserved configured MCP output mode even when MCP tools are not detected at startup, so dynamically registered MCP tools can still be decorated later. Fixed …View on GitHub ↗ -
v0.4.2 pi-tool-display 0.4.2
Release notes excerpt
[0.4.2] - 2026-06-01 Changed - Deferred config modal, settings inspector, and built-in tool metadata loading until needed to reduce startup work. - Replaced shared agent-directory lookup with a local PI_CODING_AGENT_DIR-aware resolver for config and capability checks. - Widened peer dependency ranges to ^0.74.0 || ^0.75.0 || ^0.77.0 || ^0.78.0. Fixed - Corrected classic-mode diff line-number gutter spacing.View on GitHub ↗
FAQ
Can I use it with Claude Code or another coding agent?
Do MCP tools need to be available at startup?
pi.registerTool to capture tools as they register. If MCP is unavailable at startup, its settings may be hidden from the modal while the configured output mode is preserved.How can I avoid conflicts with another extension that renders a built-in tool?
false in registerToolOverrides, then run /reload.