Skip to main content
Glama

MINT Protocol — Universal Work Attestation

Mint Join Cell

mint_join_cell

Join an open work cell by locking its required stake.

Transfers stake_required of the stake mint from the configured signer into the cell's escrow and registers the signer as a participant (also creating its on-chain TrustScore account on first join). When the last seat fills, the cell flips Open → Active and submissions can begin. Fails if the cell is full or already active.

Input Schema

NameRequiredDescriptionDefault
cell_idYesthe id of the cell to join (the same id used at creation).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the whole burden and does well: it discloses the stake transfer into escrow, participant registration, first-join TrustScore account creation, the Open → Active state flip, and failure conditions for full/active cells. It stops short of saying whether the stake is refundable or how a signer later exits, which matters for a value-moving mutation.

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

Conciseness5/5

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

Front-loaded with the action and mechanism, then effects, then the state transition, then failure modes — every sentence contributes and there is no 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?

An output schema exists, so return values need not be described, and the description covers side effects, state changes, and error conditions. The main remaining gap is post-join economics — whether stake is recoverable or slashable — and any signer-balance/approval prerequisites.

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?

Only one parameter exists and the schema documents it at 100% coverage ('the same id used at creation'), so the schema does the work. The description adds contextual meaning by tying the join to the stake mint and configured signer, but adds no new detail about the cell_id itself.

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?

The first sentence names a specific verb (join) and resource (open work cell) and states the mechanism (locking its required stake). It is clearly distinguishable from sibling mutations like mint_create_cell or mint_settle_cell, which operate on different lifecycle stages.

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 description gives explicit preconditions and exclusions: the cell must be open and not full, otherwise the call fails. It does not name sibling alternatives (e.g., create a cell instead, or settle one), so routing guidance is present but not fully comparative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.