A side-by-side diff viewer for the terminal that knows your code: hover a symbol in the diff for its type and docs from the language server, and leave review notes at lines for an agent such as Claude Code to answer. One key switches between the changed hunks and the whole file.
seam is not a pager like delta or diff-so-fancy, which colour the output of
git diff: it reads the repository itself, holds both versions of each
file, and lets you move through them.
Side by side, or one column when the terminal is narrow
The changed hunks or the whole file, one file at a time or all of them in one stream
Hover and go-to-definition through the language server, on the new side and the old one, also when comparing commits
Syntax colours for Go, Rust, JavaScript, TypeScript, JSX, TSX, HTML, PHP and Python, and any other language chroma knows, by configuration
Changed words marked within a line
Review notes: questions and findings at lines of the diff, set with a key or a click in the gutter, which follow their lines through edits and belong to the branch they were set on
seam mcp, so that an agent such as Claude Code or OpenCode reads your
notes and answers them at the line, and S sends the waiting notes to a
running Claude Code session (see Agents)
Files or directories on disk compared with --files, also as
git difftool
A file list grouped by folder, and reload on change with --watch
Keys, colours and servers configurable in one TOML file
Related MCP server: nvim-mcp
Linux or macOS
git 2.36 or newer
A terminal with mouse support for hover; without one, the caret does it
For hover, the language server of the language, see Language servers
To build: Go 1.27
Each release has a static
binary for Linux and macOS on amd64 and arm64, which needs nothing else
but git:
# macOS, with Homebrew
brew install --cask dturcinovic/tap/seam
# Debian, Ubuntu
sudo apt install ./seam_<version>_amd64.deb
# Fedora and other rpm systems
sudo dnf install ./seam-<version>-1.x86_64.rpm
# Any Linux: unpack and put seam on the PATH
tar -xzf seam_<version>_linux_amd64.tar.gz seam && mv seam ~/.local/bin/checksums.txt in the release holds the SHA-256 of each file.
With Go 1.27:
go install github.com/dturcinovic/seam/cmd/seam@latestOr from a clone, with Task:
task build # bin/seamseam --version names the release, the commit and its date, and
seam upgrade brings an install to the latest release (see
Upgrading).
In a git repository with changes:
seam # HEAD against the worktree
seam main # main against the worktree
seam HEAD~1 HEAD # the last commit
seam --staged # what is staged
seam --files a b # two files or directories on diskKey | Does |
| Next, previous file |
| Next, previous change |
| Hunks or the whole file |
| Side by side or one column |
| One file or all files in a stream |
| File list |
mouse at rest | Hover |
| Go to the definition, |
| Caret: |
| A note at the caret's line, or click |
| All notes |
| Quit |
Usage: what seam compares, the views, the keys and the mouse, notes and agents
Language servers: which ones, how to install them, and their workspaces
Configuration: config.toml with every key
See CONTRIBUTING.md.
Take review notes the user left in seam, a terminal diff viewer, in order to answer them: without arguments the open and sent notes, leaving out notes of other branches than the checked-out one; with ids those notes; with batch the notes the user sent to this session. Giving both ids and batch fails, and so does a batch that does not exist. Taking reserves the notes for this session so that no other agent session answers them; they stay reserved until this session exits or the user gives them back, and after a crash only the user can, so take only what you will answer. Each note comes with its file, its lines and the lines around them, the user's text and earlier answers; the call returns one claim to give seam_reply with each answer. Notes it cannot take come back under refused with the reason: unknown, taken (by any session, this one too), answered, resolved, other_session (the batch went to another session) or rebatched (sent again or edited since; leave those). It takes at most 20 notes per call; when more is true, call again for the rest. To read notes without reserving them, use seam_notes_view.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | the notes, by id; without ids and batch all open or sent ones of the branch checked out | |
| batch | No | the batch a message from seam's channel named; not with ids |
| Name | Required | Description |
|---|---|---|
| more | Yes | more open notes are left for another call |
| claim | Yes | to give seam_reply with each answer to these notes |
| notes | Yes | |
| refused | Yes | notes of ids not taken, and why |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this non-read-only and non-idempotent; the description justifies that by disclosing the reservation model, how long reservations last, the crash case where only the user can release them, and the full refusal taxonomy (unknown, taken, answered, resolved, other_session, rebatched). The only missing piece is the shape of the returned note content, which the output schema covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and dense with information; nearly every clause carries a rule (limits, failures, refusal reasons). Some sentences are syntactically knotty ("with ids those notes"; "and so does a batch that does not exist"), costing a little readability, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers mode selection, reservation lifecycle, per-note payload contents, the 20-note ceiling with a retry instruction, page-again behavior, and a complete refusal reason vocabulary. Combined with the existing output schema, an agent has everything needed to call and interpret it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it spells out the mutual-exclusion failure between ids and batch and clarifies that batch refers to a batch named by seam's channel. Minor gap: no guidance on how many ids can be passed relative to the 20-note cap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Take review notes the user left in seam") and immediately frames the goal ("in order to answer them"). It distinguishes itself from both siblings: seam_notes_view is named as the non-reserving alternative and seam_reply is named as the consumer of the returned claim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Enumerates all three invocation modes and what each selects: no arguments = open/sent notes on the checked-out branch, ids, or batch. It also gives explicit negative guidance (ids + batch fails, nonexistent batch fails) and a caution about when not to over-take ("take only what you will answer"), plus an alternative tool for read-only access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the user's review notes without taking them: those of ids, or without ids every note that is not resolved, leaving out notes of other branches than the checked-out one, and including notes another session has taken. It reserves and changes nothing, and leaves out ids it does not know; use it to look before taking or to see what was answered. To answer notes, take them with seam_notes first and reply with seam_reply.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | the notes, by id; without ids all not resolved of the branch checked out |
| Name | Required | Description |
|---|---|---|
| notes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds useful behavioral context: it reserves and changes nothing, excludes notes from other branches, includes notes another session has taken, and omits unknown ids. It does not describe return format, but an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core read-only purpose and then covers filtering and alternatives. It is dense and slightly run-on, but every sentence contributes useful selection or usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, full schema coverage, annotations, and an output schema, the description provides everything needed to select and invoke the tool correctly. It covers scope, branch filtering, unknown ids, and the relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single ids parameter is already documented. The description reinforces that ids select specific notes and that omitting ids returns all unresolved notes on the checked-out branch, but it adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: read the user's review notes without taking them. It clearly distinguishes this from seam_notes (taking notes) and seam_reply (answering notes), and specifies scope by ids or unresolved notes on the checked-out branch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool to look before taking or to see what was answered. It also names the alternatives and the required sequence for answering notes: take them with seam_notes first and reply with seam_reply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a review note, giving the claim seam_notes returned with it; the answer, in Markdown, shows at the note's lines in seam right away and the note is marked answered. Sending the same text under the same claim again adds nothing and returns the earlier reply, so a lost answer can be sent again. An answer under an older claim, after the user gave the note back and it was taken again, is kept but leaves the note to the newer taker, and late is true. It fails on an unknown or resolved note, an empty answer, or one over 64 KiB.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the note | |
| text | Yes | the answer, in Markdown | |
| claim | Yes | the claim seam_notes returned with it |
| Name | Required | Description |
|---|---|---|
| late | Yes | the note was taken again since; the answer is kept but leaves it taken |
| reply | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-destructive, idempotent write, but the description adds substantial context the annotations cannot: the immediate visibility of the answer, the answered-note state change, dedup returning the earlier reply, the older-claim case returning late=true, and specific failure conditions (unknown/resolved note, empty text, >64 KiB).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and effect, followed by idempotency, edge case, and failure modes in a logical order. The prose is a dense run-on in places ('giving the claim seam_notes returned with it'), but nearly every clause carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter mutation with an output schema already documenting return values, the description covers what changes, retry safety, concurrency/staleness, size limits, and error cases. An agent has everything needed to call it correctly and interpret the 'late' flag.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds workflow meaning: 'claim' is a token obtained from seam_notes whose freshness determines whether the answer lands with the current taker or is marked late, and 'id' must refer to an unresolved note. That is real semantics beyond the bare schema strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Answer a review note') plus the required claim from the sibling tool, and describes the visible effect (answer appears at the note's lines, note marked answered). An agent can distinguish this from seam_notes and seam_notes_view without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong usage context: the claim must come from a prior seam_notes call, and retries after a lost answer are explicitly safe. It also explains the stale-claim scenario. It stops short of naming when to use a sibling instead (e.g., seam_notes_view for read-only inspection), so it is clear but not exhaustively routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0seam_notesseam_notes_viewseam_replyScored across 3 tools
Each tool has a distinct role: seam_notes claims notes for answering, seam_notes_view inspects them without side effects, and seam_reply submits answers. The potentially overlapping read operations are explicitly differentiated by reservation behavior and intended use.
All names use snake_case and a consistent seam_ prefix, making them readable as one tool family. However, they mix noun-based and verb-based forms, and seam_notes_view places the action after the resource rather than following a uniform verb_noun pattern.
Three tools are well matched to the narrowly scoped review-note workflow. Each earns its place by covering inspection, exclusive claiming, and replying without adding redundant operations.
The surface covers the complete agent workflow of discovering notes, safely inspecting or claiming them, and submitting idempotent answers. Pagination, refusal states, stale claims, and other workflow edge cases are also addressed without obvious dead ends.
Human feedback for AI agents: share HTML, get a live review link, read anchored notes as markdown.
Publish agent output for human review; collect comments; agents read them back in-session.
A notebook your coding agents write to: notes that track the code's commit, and handoffs.
Live PR/MR code reviews via review_url_code. OAuth or portal Bearer auth.
