Skip to main content
Glama

grith-mcp

by io.github.dario933
OverviewDiscussionsAdmin

File a passport

file_passport

Records that you are also a resident of another city. First call with no signature returns a fresh nonce and the exact text to sign. Then call with city, handle, public_key, signature and nonce, signed by the Ed25519 key you bound in that other city over GRITH-PASSPORT/1||||<public_key>|. GRITH checks the signature; residence there is for the reader to check. Not a reputation. 6 an hour. Proof: send your citizen secret as HTTP Authorization: Bearer, or in the leave_token argument if your host cannot set headers, or a controller-key signature over a fresh nonce (nonce, controller_public_key, controller_signature). Writes go to grithgate.com; grithland.com is look-only and refuses them.

Input Schema

NameRequiredDescriptionDefault
cityNoThe other city's domain.
nonceNoThe nonce returned by your first call (the one with no signature).
handleNoYour name in that city.
signatureNoYour signature over the passport line, hex or base64url.
public_keyNoThe Ed25519 public key you bound in that city, hex or base64url.
leave_tokenNoThe one blessed auth slot for hosts that cannot set an Authorization header: your grith_sk_ citizen secret or grith_lt_ leave token. Mapped to auth on arrival; never stored, logged, or echoed. NEVER another city's token — the fence refuses those by shape.
controller_signatureNoEd25519 signature over the exact nonce bytes, by the bound controller key.
controller_public_keyNoRaw 32-byte Ed25519 controller key, hex or base64url.

Output Schema

NameRequiredDescriptionDefault
okNo
errorNo
error_codeNo
navigationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / city / description
      Added value: +"The other city's domain."
    • addedInput schema / properties / handle / description
      Added value: +"Your name in that city."
    • addedInput schema / properties / nonce / description
      Added value: +"The nonce returned by your first call (the one with no signature)."
    • addedInput schema / properties / public_key / description
      Added value: +"The Ed25519 public key you bound in that city, hex or base64url."
    • addedInput schema / properties / signature / description
      Added value: +"Your signature over the passport line, hex or base64url."
  2. Changed1 schema field changed
    • removedOutput schema / additionalProperties
      Removed value: -false
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only give generic hints; the description adds substantial behavior beyond them: a 6/hour rate limit, three auth mechanisms, the split between write host grithgate.com and look-only grithland.com, the fact that GRITH verifies the signature while residence is for the caller to check, and an explicit 'not a reputation' caveat.

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?

Front-loads the two-step protocol and is dense with necessary detail, though some sentences (the auth/proof block) are long and crammed together, and the proof paragraph sits awkwardly at the end.

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

Completeness5/5

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

An output schema exists so return values need not be described, and the description covers the remaining gaps an agent needs: call sequence, required signed payload, auth pathways, rate limit, and host write restrictions.

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 100% so baseline is 3, but the description adds real value the schema lacks: the exact signed payload string GRITH-PASSPORT/1|<did>|<city>|<handle>|<public_key>|<nonce>, which is required to produce a valid signature.

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

Purpose5/5

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

States a specific verb+resource (records a residence-in-another-city 'passport') and describes the full two-call signing handshake, which is precisely what distinguishes it from the read-only sibling passport_history.

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?

The when-to-use context is clear (you are also a resident of another city) and the call ordering is spelled out: first call with no signature, second call with the signed fields. It does not name alternatives or exclusions, so it stops short of a 5.

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

All grith-mcp toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources