Skip to main content
Glama
forestrie

mcp-register

by forestrie
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Delegate sealing for your log

delegate_sealing

Authorize an operator's sealer to publish signed checkpoints for your Forestrie data or authority log, so entries get sealed until expiry. Run once per log.

Instructions

Authorise the operator's sealer to publish checkpoints for your data log, signed with the log key. Without it entries sequence but are never sealed. If the coordinator has not learned the log's public root, this calls canopy's prepare with the same grant first. Run once per log; the delegation lasts until the returned expiresAt. With as: "authority" it does the same for your authority log, signed with the authority key, so the child grants you register there get sealed.

Input Schema

NameRequiredDescriptionDefault
asNowhich key owns the log: "log" (default) for your data log, under the grant you register statements with; "authority" for your authority log, under its creation grant (FORESTRIE_AUTHORITY_GRANT), so the child grants register_grant sequences there get sealed
grantNothe Forestrie-Grant: base64 (standard or URL-safe) of the completed grant, or a path to a file holding it as raw bytes or base64 text; falls back to FORESTRIE_GRANT
baseUrlNothe canopy SCRAPI base URL; falls back to FORESTRIE_BASE_URL — never defaulted by the package itself
ttlSecondsNohow long the delegation lasts; defaults to the coordinator's suggestion
coordinatorUrlNothe delegation coordinator base URL; falls back to FORESTRIE_COORDINATOR_URL
knownSealerKeyNothe registrar's voucher key, base64 of 64 bytes x‖y, as the operator publishes it; falls back to FORESTRIE_KNOWN_SEALER_KEY

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false, so the safety profile is covered. The description adds real behavioral value beyond that: the conditional chained call to canopy's prepare when the coordinator hasn't learned the public root, the one-time-per-log nature, and that the delegation expires at the returned expiresAt. Auth/grant context is largely left to the schema.

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?

Purpose is front-loaded, then consequences, then the chained prepare step, then the authority variant. Dense but every sentence carries information for a six-parameter tool. Slightly run-on phrasing but no wasted filler.

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?

For a mutation tool with no output schema, the description covers the effect, the conditional prerequisite call, the lifetime of the result, and the key/variant distinction. Combined with 100% schema coverage, an agent has what it needs; minor gaps remain around failure modes and permission requirements.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all six parameters thoroughly, including the as enum and env-var fallbacks. The description restates the 'as: authority' semantics but adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

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?

States a specific verb and resource: 'Authorise the operator's sealer to publish checkpoints for your data log, signed with the log key.' The scope and effect are unambiguous, and the authority variant is distinguished from the default data-log behavior. No sibling tool is named for contrast, so it stops just short of full sibling differentiation.

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?

Gives clear context: 'Without it entries sequence but are never sealed' explains why the tool is needed, and 'Run once per log' sets a usage constraint. It does not name alternatives or explicit when-not conditions relative to siblings like register_grant or issue_grant.

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

Deploy Server

Other Tools