Writes a SHA-256 hash of the sort log into a Solana devnet memo transaction, and verifies a seal by recomputing the log hash and checking it against the chain. Only the hash goes on-chain — never file names or contents.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cullyard scan my Bali folder and sort photos into Picks, Maybe, and Rejects"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Tell your agent how to sort. Watch the folders move.
Cullyard is a local MCP server with a desk in the browser. Claude Code, Antigravity or any other MCP client reads every file in a folder, sorts it into lanes (Picks, Maybe, Rejects, or lanes you name), and trims or resizes copies when you ask. The desk at http://127.0.0.1:4870 shows each move as it happens, and you can drag cards back if you disagree. When a sort is done, the agent can write a SHA-256 of the sort log into a Solana devnet memo, so anyone holding the log can check later that it was not edited.
Kind | Examples | What the agent sees |
image | jpg, png, webp, heic, avif, gif, tiff | width, height, format |
raw | cr2, cr3, nef, arw, dng, raf | width, height when the decoder can read it |
video | mp4, mov, mkv, webm, avi, mts | duration, codec, frame size |
audio | mp3, flac, wav, m4a, ogg, opus | duration, title, artist |
page count | ||
document | docx, xlsx, csv, pptx, md, epub | kind and size |
archive, design, code, other | zip, psd, blend, py, anything else | kind and size |
Unknown extensions are still listed as other. The desk never refuses a file because of its extension.
Related MCP server: FilePilot AI
You need Node.js 20 or newer. FFmpeg ships inside the package, so trimming works on a clean Windows machine.
Claude Code:
claude mcp add cullyard -- npx -y github:bryankwandou/cullyard "D:\Shoots\Bali"Antigravity, Cursor, Claude Desktop or any client that reads an mcpServers block:
{
"mcpServers": {
"cullyard": {
"command": "npx",
"args": ["-y", "github:bryankwandou/cullyard", "D:\\Shoots\\Bali"]
}
}
}Replace the folder with your own. The desk opens on 127.0.0.1:4870 (set CULLYARD_PORT to change it). Pass --no-desk if you only want the MCP tools.
To seal runs on devnet, set CULLYARD_KEYPAIR to the path of a devnet keypair JSON file. Without it, sorting and editing work the same and seal_run returns a clear error.
Tool | What it does |
| Lists every file with kind, size, pixel size, duration, tags or page count |
| Metadata for one file |
| Current lanes and which file sits where |
| Adds a lane, such as "Hero shots" or "Client docs" |
| Moves a file into a lane folder, with an optional reason shown on the desk; never overwrites |
| Measures focus, exposure and bursts for every photo, ranks them against each other |
| One numbered grid of up to 16 photos, returned as an image the agent can look at |
| One photo as an image (up to 1024 px), plus its measurements |
| Writes a resized WebP, JPG, PNG or AVIF copy |
| Cuts a time range from video or audio without re-encoding |
| SHA-256 of the sort log, computed locally |
| Writes that hash into a Solana devnet memo |
| Recomputes the hash and checks it against the chain |
| The file kinds Cullyard recognises |
Rules the server enforces: paths outside the workspace are refused, moves never overwrite, edits always write a new file, and the original is never touched.
Metadata alone cannot tell a sharp frame from a blurred one, so Cullyard gives the agent two kinds of evidence.
Pictures. contact_sheet and preview_image return real images over MCP, so a vision model such as Claude looks at the photos instead of guessing from file names. The sheet numbers each frame, and the legend maps numbers back to files.
Measurements. assess_photos measures each photo and compares it with the rest of the set:
Focus: variance of the Laplacian on a contrast-stretched greyscale copy, measured per tile on a 4×4 grid. The sharpest tile counts, so a sharp subject on a soft background still reads as sharp, and a dark frame is not mistaken for a soft one.
Exposure: mean brightness and the share of clipped shadows and highlights.
Bursts: a 64-bit difference hash plus a 3×3 colour print. Two frames are one burst only when both match, so the same framing at golden hour and at blue hour stays separate. The sharpest frame of each burst is kept; the others are flagged duplicate.
Flags: soft (under 40% of the set's median focus), dark, bright, duplicate. Rank puts clean frames first, sharpest first.
The results are saved in .cullyard/quality.json, and the desk shows them on each card, so you see the same evidence the agent used. The numbers are signals, not verdicts: a shallow-focus portrait or a night shot can be a keeper with "bad" numbers, which is why the agent also looks at the picture.
scripts/demo-agent.mjs drives the real server over stdio, the same way an agent does. It scans twelve sample files, creates a "Client docs" lane, measures the seven photos, looks at them on a contact sheet, sorts photos from what it measured (with a reason on every move), files the other four, resizes the top pick to 1200 px WebP, trims three seconds from a clip, seals the log on devnet and verifies the seal. The full output is in docs/agent-transcript.txt, and the recorded desk is in web/media/walkthrough.mp4.
npm install
node scripts/make-samples.mjs demo-workspace
CULLYARD_KEYPAIR=path/to/devnet-keypair.json node scripts/demo-agent.mjs demo-workspaceThe seal from the recorded run is in web/proof.json and can be opened on Solana Explorer.
Every move appends one JSON line to .cullyard/log.jsonl inside the workspace. seal_run hashes the log with SHA-256 and sends one transaction to the Memo program (Memo1UhkJRfHyvLMcVucJwxXeuD728EqVDDwQDxFMNo) with the text:
cullyard:v1 log=<sha256> entries=<count>verify_seal fetches that transaction, hashes the log lines written before the seal, and compares the two. File names and file contents never go on-chain; only the hash does.
npm testEighteen tests cover file kinds, scanning, lanes, path traversal, no-overwrite moves, resizing, video probing, the desk's upload and cross-origin guard, the seal digest, photo measurement (blur, a sharp subject on a soft background, dark frames, bursts, colour-separated framings), the contact sheet, and a full MCP stdio round trip that includes the image tools.
bin/ command-line entry (MCP over stdio, plus the desk)
src/ scan, lanes, edit, look (photo measurement), seal, MCP server, desk server
desk/ the browser desk (plain HTML, CSS, JS; English and Indonesian)
web/ landing page, screenshots, walkthrough video, proof.json
scripts/ sample generator and the demo agent
test/ node:test suites
docs/ report and agent transcript
pitch/ pitch deck
video/ marketing videoThe photo thresholds were tuned on generated test images, not yet on a real shoot. Treat flags as hints and check the contact sheet.
Image tools need an MCP client that shows image results to the model. Claude Code does; other clients were not tested.
There is no timeline editor. Trim and resize are single steps.
Seals use devnet only.
MIT
Measure sharpness (per region, so a sharp subject on a blurred background still scores well), exposure and clipping for each photo, find near-duplicate bursts and mark the sharpest frame of each, and rank the set. Flags are relative to the set: soft, dark, bright, duplicate. Treat them as evidence, then look with contact_sheet or preview_image before rejecting a photo.
| Name | Required | Description | Default |
|---|---|---|---|
| lane | No | use every image in this lane; omit both to use the inbox | |
| files | No | paths relative to the workspace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that flags are relative to the set (soft, dark, bright, duplicate) and that regional sharpness prevents penalizing a sharp subject on a blurred background. It frames flags as evidence rather than verdicts, though it doesn't describe the return format or processing cost.
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 measurement actions, followed by flag semantics and the follow-up instruction. Dense but every clause earns its place; 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?
For a two-parameter read/analysis tool with no output schema, the description covers what is measured, how flags are interpreted, and the recommended verification workflow. Sufficient for correct invocation, though return structure is unspecified.
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 lane and files are already documented by the schema. The description adds meaning about set-relative scoring and per-region analysis but nothing specific about parameter syntax or interaction between lane and files. Baseline 3 is appropriate.
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 specific verbs and resources: measures sharpness per region, exposure, clipping, finds near-duplicate bursts, marks sharpest frame, and ranks the set. This is clearly distinguishable from siblings like contact_sheet and preview_image, which are mentioned as follow-ups rather than overlapping tools.
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?
Explicitly instructs to treat flags as evidence and to consult contact_sheet or preview_image before rejecting a photo, naming the alternatives and the workflow context. It does not state when not to use this tool, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return up to 16 photos as one numbered grid image you can look at, with a legend mapping numbers to files. Use it to compare a set: composition, faces, closed eyes, missed focus.
| Name | Required | Description | Default |
|---|---|---|---|
| lane | No | use every image in this lane; omit both to use the inbox | |
| files | No | paths relative to the workspace | |
| offset | No | skip this many photos, to page through a large set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description still discloses two key behavioral traits: a hard cap of 16 photos and the fact that output is a single composite image rather than individual files. It omits permission/read-only framing and what happens when a set exceeds 16 (paging is only implied by the schema's offset).
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?
Two sentences, zero waste. The output shape is front-loaded before the usage hint, which is the right order for an agent that needs to know what it gets back.
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-optional-parameter tool with no annotations and no output schema, the description covers the return artifact, the legend mechanism, and the size cap. The only gap is how a >16 set behaves relative to offset, which is left to the schema.
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 lane, files, and offset are already fully documented in structured data. The description adds only the implicit 16-item ceiling that motivates offset paging, which is marginal value. Baseline 3 applies.
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 (return) plus a precise output artifact: a numbered grid image with a legend mapping numbers to files. An agent can immediately distinguish this from preview_image (single image) or assess_photos without opening either 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?
"Use it to compare a set: composition, faces, closed eyes, missed focus" gives clear contextual guidance on when this tool fits. It does not name alternatives (preview_image, assess_photos, describe_file), so the agent must infer exclusions on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a custom lane, for example "Hero shots" or "Final cut".
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for a mutation tool. It does not disclose whether lane names must be unique, what happens if a lane with that name already exists, whether the operation is reversible, whether permissions are required, or what is returned on success.
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?
One short sentence, front-loaded with the verb and resource, with the examples doing efficient work. 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?
For a write operation with zero annotation coverage and no output schema, the definition is thin: an agent cannot tell from it what a successful call returns, how duplicates are handled, or where the new lane appears in relation to list_lanes. The name semantics are the only thing fully covered.
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 0%, so the description must compensate for the single 'name' parameter. The examples ('Hero shots', 'Final cut') usefully convey that names are human-readable display labels rather than IDs, but they add no detail on length limits or character constraints, leaving the schema's minLength/maxLength undocumented.
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 ('Create a custom lane') and clarifies the otherwise opaque concept of a 'lane' with concrete examples ('Hero shots', 'Final cut'). It does not explicitly name or contrast with the siblings list_lanes and move_to_lane, so it falls short of a 5.
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?
The examples hint at the domain but the description never says when to create a lane versus using list_lanes to inspect existing ones or move_to_lane to assign assets. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return kind and metadata for one file in the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | path relative to the workspace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only lookup by saying 'Return', but it does not say what happens when the file is missing, whether paths are validated, what permissions are required, or what 'kind' means.
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 definition is a single tight sentence with the core action and scope front-loaded. There is no redundant or filler text.
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 simple one-parameter read tool, the description is minimally adequate, but because there is no output schema it does not explain the return shape beyond 'kind and metadata'. Missing-file behavior and metadata field details are also left unstated.
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?
The single parameter is fully documented in the schema as a path relative to the workspace, and the description adds no additional syntax, constraints, or examples. With high schema coverage, the baseline of 3 is appropriate.
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 gives a specific verb ('Return') and resource ('kind and metadata for one file in the workspace'), so it is immediately clear what the tool does. It does not name or distinguish itself from any sibling tool, but no sibling appears to overlap directly with describing a single file.
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?
The phrase 'for one file in the workspace' implies this is for a known single file, but the description does not state when to use this instead of scan_workspace, list_kinds, or other discovery tools. There are no explicit when-to-use, when-not-to-use, or alternative-routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the file kinds Cullyard recognises.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. 'List' reasonably implies a read-only, non-destructive operation, but the definition says nothing about whether the set is static, whether it is exhaustive, or what the returned items look like. Risk is low for a zero-parameter tool, so this is adequate but not thorough.
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?
A single front-loaded sentence with no filler. It is arguably too sparse for a tool with no output schema, but nothing in it is wasted.
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?
With no output schema and no annotations, the description should at least hint at the return shape (list of kind names or identifiers) and their purpose. As written, an agent knows what the tool does but not what it gets back or how to use it downstream.
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?
The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no input is needed, consistent with the empty 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?
States a specific verb ('List') and resource ('file kinds'), which is clearly distinct from siblings like describe_file or scan_workspace. It does not, however, clarify whether 'kinds' are enum identifiers usable elsewhere or human-readable labels, and gives no sibling-relative framing.
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?
There is no guidance on when to call this versus alternatives, nor any mention of what to do with the result (e.g., that kinds may be used to filter or interpret describe_file output). The agent must infer the tool's role in a workflow entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the lanes and which file sits in which lane.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. 'Return' implies a non-mutating read and it discloses the shape of the result (lanes mapped to their files), but it says nothing about ordering, size/full-scan cost, or whether empty lanes appear.
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?
A single short sentence with zero filler, and the returned content is front-loaded before any caveats (of which there are none).
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 zero-parameter list tool with no output schema, the description covers the essential question of what is returned (lane membership per file). A note on ordering or volume would close the last gap, but an agent can invoke this correctly as written.
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?
The input schema has zero parameters, so the baseline is 4 and there is no parameter semantics to add. The description's implied 'no filters' contract is consistent with the empty 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?
States a specific verb and resource ('Return the lanes') plus the payload content ('which file sits in which lane'), so the agent knows exactly what comes back. It is clearly distinct from the write-oriented siblings create_lane and move_to_lane, though the description never names them explicitly.
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?
There is no guidance on when to call this versus list_kinds, scan_workspace, or describe_file, and no prerequisites or exclusions are stated. The agent must infer that 'list every lane and its file' is an unfiltered inventory read from the wording alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current SHA-256 and entry count of the sorting log, without sending anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key behavioral trait: it reads local state and transmits nothing, so there are no side effects or data-egress concerns. It also states what is returned (SHA-256 plus entry count), though it omits any note on mutation safety or failure modes if the log is absent.
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?
A single front-loaded sentence with no filler; the resource, the returned values, and the side-effect constraint all appear immediately.
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?
With zero parameters and no output schema, the description must convey the return shape, and it does (hash + count). For a low-complexity read tool this is essentially complete, lacking only edge-case behavior when the log is empty or missing.
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?
The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The description correctly signals a no-argument call by implying the log is implicit.
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 ('Show') and specific resource content: the SHA-256 digest and entry count of the 'sorting log'. This is concrete enough to distinguish it from siblings like seal_run and verify_seal, though it never explicitly names or contrasts those alternatives.
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?
'Without sending anything' implies a purely local, no-export inspection use case, which is useful implied guidance. However, it never states when to prefer this over verify_seal or seal_run, nor any preconditions such as requiring a log to already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a file into a lane folder. Never overwrites. Give a short reason; the desk shows it to the person watching.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| lane | Yes | ||
| reason | No | why this file goes here, e.g. "sharpest of the burst" or "eyes closed" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the operation never overwrites and that the reason is visible to a person, but it does not explain permissions, failure behavior, whether the lane must exist, or what happens if the file is already in the lane.
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?
Three short sentences, front-loaded with the action, then the key safety property, then the parameter expectation. There is no wasted wording.
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 simple three-parameter mutation tool with no annotations or output schema, the description covers the main action and one important safety behavior. It remains incomplete about error conditions, lane existence requirements, and file identifier expectations.
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 only 33%, so the description needs to compensate. It adds meaning for the reason parameter by saying it is short and shown to the person watching, and it clarifies that lane refers to a lane folder. It leaves file and lane formats largely undocumented beyond common-sense interpretation.
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: move a file into a lane folder. It is clear enough to distinguish from lane-management siblings such as create_lane and list_lanes, though it does not explicitly contrast with them.
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?
Usage is implied by the action itself: use this when a file should be placed into a lane folder. However, there is no explicit guidance about when to choose this over lane-management or file-description tools, nor about prerequisites such as whether the lane must already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one photo as an image you can look at (up to 1024 px), with its measured quality. Use it to check focus on the eyes, expression or detail before deciding.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool returns an image plus measured quality and enforces a 1024 px ceiling, but it does not explicitly state that the operation is read-only, non-mutating, or free of side effects.
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?
Two tightly written sentences with no waste. The core behavior is front-loaded, and the usage guidance follows immediately.
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 simple two-parameter preview tool with no output schema, the description covers the return content and the main use case. However, it leaves parameter semantics largely unexplained and does not describe basic operational constraints beyond the maximum preview size.
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 0%, so the description must compensate. It only implies the file and size concepts indirectly through 'one photo' and 'up to 1024 px'; it does not name the required file parameter, the optional size parameter, its default, or its minimum value.
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: returns one photo as a viewable image capped at 1024 px, along with measured quality. That distinguishes it from batch-oriented siblings like contact_sheet or assess_photos, but it does not explicitly name an alternative or contrast itself with resize_image.
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?
Gives a clear intended use: inspect focus on the eyes, expression, or detail before deciding. It does not specify when not to use it or explicitly direct the agent to a sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a resized copy of an image next to the original.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| width | No | ||
| format | No | webp | |
| height | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It usefully discloses that a new file is written next to the original, implying the source is not overwritten. However, it omits overwrite behavior if the target exists, error handling, permissions, return value, and whether aspect ratio is preserved.
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 single sentence is front-loaded with the action and has no wasted words. It is appropriately concise, though its brevity contributes to the gaps captured under other dimensions.
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 four-parameter image-processing tool with no annotations, no schema descriptions, and no output schema, the description is too thin. It covers the core action and output location but leaves parameter meanings, format options, and behavioral details undocumented.
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 0%, and the description does not mention any of the four parameters (file, width, height, format). It does not explain the format enum or default, nor how width and height interact. This leaves the agent entirely dependent on undocumented schema fields.
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: writing a resized copy of an image. It also clarifies the output location ('next to the original'), which is useful. It does not explicitly differentiate from siblings such as preview_image, but the core operation is clear.
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?
There is no guidance on when to use this tool versus alternatives like preview_image or trim_media. The description implies usage but offers no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every file in the workspace with its kind, size and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It implies a read-only listing and names some returned fields, but does not disclose recursion behavior, permissions, pagination, performance implications, or other operational traits.
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 a single front-loaded sentence with no wasted language. It communicates scope and return fields efficiently.
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 zero-parameter read tool with no output schema and no annotations, the description covers the basic purpose and returned fields. However, it omits important context such as whether the listing is recursive, includes hidden files, or has any operational limits.
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?
The tool has zero parameters, so the baseline is 4. There are no parameter semantics for the description to compensate for.
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 (List), resource (every file in the workspace), and returned fields (kind, size, metadata). It is clear and distinguishable from describe_file by scope, though it does not explicitly name sibling alternatives.
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?
The description does not state when to use this tool versus alternatives such as describe_file or list_kinds. The full-workspace scope is implied, but no explicit usage guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write the SHA-256 of the sorting log into a Solana devnet memo, as proof of what was sorted and when.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full load. It usefully discloses the external side effect (writes to Solana devnet, not mainnet) and the payload (SHA-256 of the sorting log), but says nothing about wallet/auth requirements, transaction cost, failure modes, or whether the write is immutable.
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?
A single front-loaded sentence with the action first and the rationale second. Nothing wasted, nothing buried.
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?
With no annotations and no output schema, the description should say what comes back (a transaction signature or seal reference) and what prerequisites exist. It covers the what and the why but leaves the agent guessing about the return value and operational requirements.
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?
Zero parameters, so the baseline is 4. The description does not clarify where the sorting log is read from, which is the only real ambiguity for a no-argument tool, but there is no schema gap to compensate for.
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?
Names a specific verb and resource: writes the SHA-256 of the sorting log into a Solana devnet memo as a timestamped proof. It's clear what the tool produces, but it doesn't distinguish itself from the closest sibling, verify_seal, which clearly belongs to the same seal lifecycle.
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?
No explicit when-to-use or when-not-to-use guidance, and verify_seal is never mentioned as the complementary read-side tool. The phrase 'as proof of what was sorted and when' implies use at the end of a sorting run, but that is inference only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cut a time range out of a video or audio file without re-encoding.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| endSec | Yes | ||
| startSec | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Without re-encoding' is a useful trait — implying speed and lossless output — but the description does not say whether the original file is modified or a new file is produced, where output goes, or whether the operation is reversible. For a mutation tool with zero annotation coverage, that is a significant gap.
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?
A single sentence with zero waste, front-loading the verb and resource. Nothing is padded or redundant.
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-required-parameter mutation tool with no annotations and no output schema, the description is too thin. Critical details — output destination, whether the source is modified, handling of invalid ranges — are absent, leaving the agent to guess at behavior.
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 0%, so the description must compensate for three undocumented parameters, and it does not — file, startSec, and endSec are never referenced. The parameter names are largely self-explanatory, which prevents a 1, but there is no added meaning about units, formats, or edge cases.
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 — 'Cut a time range out of a video or audio file' — plus the meaningful qualifier 'without re-encoding.' The purpose is immediately clear. No sibling differentiation is needed since the listed siblings (seal_run, resize_image, etc.) are unrelated operations, so it lands just shy of a 5.
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?
The description offers no guidance on when to use this tool versus alternatives, no prerequisites, and no constraints on input (e.g., valid time ranges relative to file duration). An agent must infer all usage conditions from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recompute the log hash at seal time and compare it with the memo on Solana devnet.
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the core behavior of recomputing and comparing a hash and names the Solana devnet environment, but it omits permissions, read-only status, failure behavior, and what a successful or failed verification means.
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 definition is a single front-loaded sentence with no filler. It efficiently conveys the core operation and environment without burying the key action.
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 one-parameter verification tool with no annotations and no output schema, the description is too thin. It explains the operation at a high level but leaves the signature argument and the verification result entirely unspecified.
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?
The sole parameter, signature, has no schema description and is not mentioned in the description. At 0% schema description coverage, the description should explain what the signature identifies, but it does not add any semantic meaning beyond the schema's type and minimum length.
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 verification action: recompute a log hash and compare it against a Solana devnet memo. The resource and timing are clear, but it does not explicitly distinguish this tool from close siblings like seal_run or log_digest.
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?
The phrase 'at seal time' implies the verification context, so an agent can infer this is used after sealing. However, there is no explicit guidance about when to choose this over seal_run or log_digest, and no exclusions or prerequisites are stated.
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.2.0assess_photoscontact_sheetcreate_lanedescribe_filelist_kindslist_laneslog_digestmove_to_lanepreview_imageresize_imagescan_workspaceseal_runtrim_mediaverify_sealScored across 14 tools
Most tools target clearly distinct resources and actions: sealing (seal_run/verify_seal/log_digest), workspace inspection (scan_workspace/describe_file/list_kinds), lanes (list/create/move), and media editing (resize/trim) are well separated. The photo-inspection trio (assess_photos, contact_sheet, preview_image) has some conceptual overlap since all return quality information, though the descriptions distinguish set-level measurement, grid comparison, and single-image inspection.
Nearly all names follow a consistent snake_case verb_noun pattern (seal_run, list_kinds, scan_workspace, move_to_lane, assess_photos, resize_image). A couple deviate to compound nouns (contact_sheet, log_digest), which is a minor inconsistency but still readable and predictable.
14 tools is well within the sweet spot for this domain, covering sealing, inspection, lane management, photo assessment, and light media editing. Each tool has a clear and non-redundant role.
The surface covers the core lifecycle: scan/describe files, create/list lanes, move files, assess and preview photos, resize/trim media, and seal/verify logs. Minor gaps exist—no delete or remove-from-lane operation, no lane update/delete, and no batch move—but most workflows can be completed.
Solana MCP for wallets, trades, markets, PnL, transfers, onchain data, signable swaps and API tools.
Remote MCP for C2PA intake verifier MCP, structured receipts, audit logs, and reviewer-ready evidenc
Solana-native MCP gateway for SAP, DeFi tools, SNS identity, and x402 payments.
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
