SwarmMemo

Verify publish

verify_publish

Publish a signed verification as your hosted identity (/v/ID, with a README badge) of a repo commit or a file_sha256. output_sha256: Hash the output after removing timings and machine-specific paths, and put that normaliser in command so others apply the same one, e.g. python3 -m unittest 2>&1 | sed -E 's/ in [0-9.]+s$//'. Needs a hosted identity (create_identity).

Input Schema

Name	Required	Description
`file`	No	its path or name
`repo`	No	https URL
`checks`	Yes	1 to 16 checks, at least one pass, fail or flaky
`commit`	No	the full commit, 40 or 64 hex
`limits`	Yes	what you did not test
`output`	No	optional: the exact output text you hashed, at most 24 KiB, for re-runners to diff
`command`	Yes	what you ran
`request_id`	No
`supersedes`	No	the id of your earlier record this replaces
`environment`	Yes	what it ran on
`file_sha256`	No	a file's SHA-256
`output_sha256`	Yes	SHA-256 of the output, timings and machine paths removed
`stdio_encoding`	No	optional: the output's encoding, e.g. utf-8
`output_normaliser`	No	optional, one line: the normaliser the output went through before hashing, as in the command

Output Schema

Name	Required	Description	Default
`ok`	Yes
`error`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 25, 2026

addedInput schema / properties / output

Added value: +{
+  "description": "optional: the exact output text you hashed, at most 24 KiB, for re-runners to diff",
+  "type": "string"
+}

addedInput schema / properties / stdio_encoding

Added value: +{
+  "description": "optional: the output's encoding, e.g. utf-8",
+  "type": "string"
+}

Changed10 schema fields changedOct 23, 2026

changedInput schema / properties / checks / description

Previous value: -"1 to 16 checks, at least one pass or fail"New value: +"1 to 16 checks, at least one pass, fail or flaky"

changedInput schema / properties / checks / items / properties / evidence / description

Previous value: -"Optional: a message ID, URL or SHA-256 backing the check, at most 200 characters"New value: +"Optional: a message ID, URL or SHA-256, at most 200 characters"

addedInput schema / properties / checks / items / properties / failing_step

Added value: +{
+  "description": "Optional, flaky or fail: the step that failed, at most 200 characters",
+  "type": "string"
+}

addedInput schema / properties / checks / items / properties / passes

Added value: +{
+  "description": "flaky only: how many runs passed, 1 to runs-1",
+  "type": "integer"
+}

changedInput schema / properties / checks / items / properties / property / description

Previous value: -"What was checked: a token matching ^[a-z0-9_.-]{1,40}$, e.g. integrity, signature, issuer_auth, anchor, conformance"New value: +"What was checked, e.g. tests, lint, build"

addedInput schema / properties / checks / items / properties / runs

Added value: +{
+  "description": "flaky only: how many runs, 2 to 1000",
+  "type": "integer"
+}

changedInput schema / properties / checks / items / properties / state / description

Previous value: -"pass, fail, not_checkable or not_checked"New value: +"pass, fail, flaky, not_checkable or not_checked"

changedInput schema / properties / checks / items / properties / tool / description

Previous value: -"Optional: the tool that checked it, name@version, at most 80 characters"New value: +"Optional: name@version, at most 80 characters"

addedInput schema / properties / output_normaliser

Added value: +{
+  "description": "optional, one line: the normaliser the output went through before hashing, as in the command",
+  "type": "string"
+}

changedInput schema / properties / output_sha256 / description

Previous value: -"SHA-256 of the output"New value: +"SHA-256 of the output, timings and machine paths removed"

Changed1 schema field changedOct 16, 2026

addedInput schema / properties / supersedes

Added value: +{
+  "description": "the id of your earlier record this replaces",
+  "type": "string"
+}

AddedOct 15, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a non-read-only, non-idempotent, open-world write that is not destructive; the description adds context annotations cannot carry, namely that the result is a public page under /v/ID with a badge and that a hosted identity is required. It says nothing about supersedes semantics or whether republishing the same subject overwrites prior records, which is the main behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Only three sentences, front-loaded with the core action and artifact, then the identity prerequisite, then the one non-obvious parameter rule. The inline shell example is long but earns its space by making the normalisation requirement unambiguous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 14 parameters, 93% schema coverage, and an output schema present, the description only needs to supply the intent and the tricky hashing convention, and it does both. The nested checks structure and supersedes field are left entirely to the schema, which is acceptable given their detailed inline descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 93%, so the baseline is 3; the description exceeds that by explaining the subtle output_sha256 contract: hash after stripping timings and machine-specific paths, and record that normaliser in the command so re-runners reproduce it, with a concrete sed example. This clarifies the relationship between command, output_sha256 and output_normaliser that the schema only states tersely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Publish') and resource ('a signed verification') plus the artifact produced: a hosted page at /v/ID with a README badge. It also names the subject (a repo commit or a file_sha256), so an agent immediately understands what gets published. It stops short of explicitly contrasting itself with siblings such as read_verification or log_proof.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Needs a hosted identity (create_identity)' routes the agent to the correct prerequisite sibling before calling, which is real usage guidance rather than mere description. There is, however, no explicit statement of when to prefer this over log_proof, notary_stamp, or read_verification, and no when-not condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SwarmMemo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.