Skip to main content
Glama

Coin a trait

coin_trait

Coin a free public trait. name is a unique normalized ^[a-z0-9][a-z0-9_-]{0,63}$ world name of at most 64 characters; description defaults to empty and is at most 4,000 safe characters. Omit recipe or send null for an inert trait. A recipe is an array shorthand for use, or an object keyed only by talk, move, use, give, consume, make, go_home, with one optional wake key {on, every_seconds, then} and one optional end key {then}. Read physics first: it lists every brick, field, default, and limit. Recipes allow at most 128 effects, 8 nested levels, and 65,536 UTF-8 bytes; timer/block seconds are 1 to 86400, and wait repeat is 1 to 8. Each action key, wake program or end program may weigh at most 512 effect applications, a reach counting its max times its steps. A step's then is required on check_label, chance, wait, and reach, its else is allowed only on check_label and chance, and every other brick takes neither. A wake program never hands anything over, uses target only inside a reach, and moves only to home. An end key runs at most once after its thing ends, with nobody acting: beyond the wake program rules it never waits, names actor, or destroys, moves or labels its own thing. Copy, write, the wake and end keys, and a convert without into_kind work only on a kind, never as a law; Only a law may name into_kind or use law_place; a law_place label requires seconds from 1 to 86400, and its check reads active labels only. A label on actor or target must give seconds from 1 to 86400 or permanent: true; a source or place label may take seconds and without it stays permanent. A wake try may block or send home the resident who arrived only in a room its owner marked rough. A refused recipe names where reading stopped and the rule it met there, and nothing is stored. What each brick does: front_door section abilities. End keys: front_door section things-ending. Lost? Call front_door.

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": {
      "name": "<name>"
    },
    "name": "coin_trait"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
recipeNooptional recipe keyed by the frozen actions, one optional wake key and one optional end key; at most 128 effects, 8 nested levels, and 65,536 UTF-8 JSON bytes
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / recipe / description
      Previous value: -"optional recipe keyed by the frozen actions and one optional wake key; at most 128 effects, 8 nested levels, and 65,536 UTF-8 JSON bytes"New value: +"optional recipe keyed by the frozen actions, one optional wake key and one optional end key; at most 128 effects, 8 nested levels, and 65,536 UTF-8 JSON bytes"
  2. Changed1 schema field changed
    • changedInput schema / properties / recipe / description
      Previous value: -"optional frozen-action recipe; at most 128 effects, 8 nested levels, and 65,536 UTF-8 JSON bytes"New value: +"optional recipe keyed by the frozen actions and one optional wake key; at most 128 effects, 8 nested levels, and 65,536 UTF-8 JSON bytes"
  3. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations declare a non-read-only, open-world, non-idempotent, non-destructive operation, and the description adds genuinely behavioral context beyond that: a refused recipe reports the stopping point and violated rule and stores nothing, which tells the agent the write is atomic on validation failure. It does not cover authorization, rate limits, or what the successful result looks like, keeping it short of a 5.

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 first sentence is well front-loaded, but the remainder is one dense run-on paragraph of domain jargon with no separation between input grammar, limits, and failure behavior. Redundant restatement of the schema's name pattern and description length consumes space that could have been spent on structure.

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 complex, recipe-driven creation tool with no output schema and low schema coverage, the description supplies most of what an agent needs: recipe shape, nested limits, per-action key semantics, and validation-failure behavior. It is still incomplete on how a trait differs from a kind and on the outcome of a successful call.

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 coverage is only 33%, so the description must carry weight, and it does expand the recipe parameter substantially with its action keys, wake/end shape, effect limits, nesting depth, and byte cap. However, it also repeats schema facts verbatim (the name regex and 64-char limit, the 4,000-character description default), and the recipe grammar it gives is so compressed and self-referential that it leaves real ambiguity for the most important parameter.

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?

The opening sentence 'Coin a free public trait' gives a specific verb and resource, and the name/recipe constraints make the operation concrete. It never differentiates itself from adjacent creation tools such as invent_kind or revise_kind, so an agent cannot tell from the description alone which creation path applies.

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

Usage Guidelines2/5

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

There is no explicit when-to-use/when-not-to-use guidance and no named alternative among the siblings. 'Read physics first' is a prerequisite for authoring a recipe rather than a usage-selection rule, and 'Omit recipe or send null for an inert trait' is parameter guidance, not tool-selection 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.