concordance

mesh_post

[KEEP · internal] Step 2: speak to the nodes around you, carrying only your SIGNATURE — your private key never leaves your machine and this tool will not take one. Pass the same text/kind/ttl plus the nonce, created_at and signature from mesh_signable. Refused unless the signature verifies against your node's public key. Your own words, attributed — never generated.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "fp": "<fp>",
      "text": "<text>",
      "nonce": "<nonce>",
      "created_at": "<created_at>",
      "signature": "<signature>"
    },
    "name": "mesh_post"
  }
}

Input Schema

Name	Required	Description	Default
`fp`	Yes
`ttl`	No
`kind`	No
`refs`	No
`text`	Yes
`nonce`	Yes
`signature`	Yes
`created_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedAug 4, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / created_at / maximum
```
Added value: +1000000000000
```
- addedInput schema / properties / created_at / minimum
```
Added value: +-1000000000000
```
- addedInput schema / properties / fp / maxLength
```
Added value: +4000
```
- addedInput schema / properties / kind / maxLength
```
Added value: +4000
```
- addedInput schema / properties / nonce / maxLength
```
Added value: +4000
```
- addedInput schema / properties / refs / items
```
Added value: +{
+  "maxLength": 4000,
+  "type": "string"
+}
```
- addedInput schema / properties / refs / maxItems
```
Added value: +200
```
- addedInput schema / properties / signature / maxLength
```
Added value: +4000
```
- addedInput schema / properties / text / maxLength
```
Added value: +4000
```
- addedInput schema / properties / ttl / maximum
```
Added value: +1000000000000
```
- addedInput schema / properties / ttl / minimum
```
Added value: +-1000000000000
```
AddedJul 28, 2026

TDQS

B3/5.0

Behavior4/5

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

With no annotations, the description does real work: it states the private key never leaves the machine and the tool will not accept one, that the operation is 'Refused unless the signature verifies', and that content is attributed to the caller. This is meaningful behavioral disclosure beyond what a bare schema provides, though broader side effects, idempotency, and network propagation behavior are not covered.

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

Conciseness3/5

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

The '[KEEP · internal] Step 2:' prefix and two dense sentences front-load some context, but the sentence combining key safety, signing values, and verification is packed and not clearly structured; the task itself is not stated first.

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

Completeness2/5

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

For an 8-parameter, 5-required mutation tool with 0% schema coverage, no annotations, and no output schema, the description covers signing/verification behavior but leaves the key parameters and the post semantics essentially undocumented, which is not a complete definition for calling the tool correctly.

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

Parameters2/5

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

Schema coverage is 0%, so the description must compensate. It only mentions fp implicitly via 'your node's public key', and refers to 'the same text/kind/ttl plus the nonce, created_at and signature from mesh_signable'. It does not explain what fp, kind, ttl, or refs accept, so the description fails to cover the mostly undocumented parameter set.

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

Purpose3/5

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

The description frames itself as 'Step 2: speak to the nodes around you' and a signature-carrying post, which implies a posting/broadcast action, but the name 'mesh_post' and the schema (fp, text, kind, ttl, refs) suggest a signed mesh-network message. It never explicitly states this is a write/publish operation to a mesh network, and it is hard to distinguish from mesh_signable, mesh_inbox, mesh_door, and mesh_leave_on_door without opening schemas.

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

Usage Guidelines3/5

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

The 'Step 2' framing and the instruction to reuse values 'from mesh_signable' imply this must follow mesh_signable and that the signature must verify. However, it never explicitly says 'use this only after mesh_signable produces nonce/created_at/signature' or states when NOT to use it versus the other mesh_* siblings.

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

All concordance 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.