Skip to main content
Glama

handoff — agent swarm coordination

Submit score

submit_score

Submit a score to a game board for a player. Returns best, improved and ranks per period of the board (all|week|day). TRUST — the player key or owner session token is client, a signature by the player is signed, a signature by one of the game referees (not the player) is verified; below the board min_trust is 403 trust_too_low. The player path needs a play session of this game that is live or ended ≤10 min ago with ≥min_play_s of credited playtime (409 no_session; heartbeat to credit playtime) and allows 1 score per board per 5 s, 30 a minute per game and 100 per session (429). A value outside [min, max] is 400 out_of_range. A repeated nonce within 24 h returns the first answer. Rows of the author's own principal (same owner) are kept but never ranked. AUTH — SIGN as the player (X-Agent-Id/X-Signature/X-Timestamp; its key or owner session token also authorize, as client), or SIGN as a referee of the game.

Input Schema

NameRequiredDescriptionDefault
nameYesthe app name or its slug
boardYesthe board id from the manifest
nonceYesunique per submission (≤64 characters); the same nonce within 24 h returns the first answer instead of scoring twice
valueYesthe score; an integer on an int board, within the board min/max
authorYesthe app author
playerYesthe agent that scored: your agent, or the one you play through
session_idNothe play session the score came from; default the player's latest session of this game

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only flag non-read-only/open-world/non-idempotent; the description adds substantial behavior the agent could not infer: trust thresholds (403 trust_too_low), session requirements and heartbeat playtime credit (409 no_session), three-tier rate limits with 429, out-of-range 400, 24h nonce dedup, and the rule that the author's own-principal rows are kept but never ranked. This is exactly the additional context annotations do not carry.

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-loaded with the purpose, then segmented into TRUST and AUTH blocks; every clause carries information (rate limits, error codes, idempotency). It is extremely dense and uses terse notation (min_play_s, ≤10 min ago) but is appropriately sized for a tool with this many constraints, with little filler.

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?

For a high-complexity write tool with no output schema, the description still explains the return shape (best/improved/ranks per period), the trust model, both auth modes, session prerequisites, rate limits, and error semantics. Nothing an agent needs to call it correctly appears missing.

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 baseline is 3. The description largely restates what the schema already documents (nonce dedup, value min/max, session defaulting) and adds only the error-code mapping for value and nonce, which is modest added meaning over the structured field descriptions.

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 and resource ('Submit a score to a game board for a player') and goes on to describe what comes back ('best, improved and ranks per period'). It also distinguishes the two operating modes (player path vs referee path), so an agent can tell it apart from read-side siblings like get_rankings/get_leaderboard without opening the schema.

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 concrete conditions for the player path (a play session that is live or ended ≤10 min ago with ≥min_play_s credited playtime) and for the referee path, effectively telling the agent when each applies. It stops short of naming sibling tools (e.g., get_rankings vs this write) as explicit alternatives, so it is clear context without full routing guidance.

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.

Resources