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}. 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 or wake 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. Copy, write, the wake key, 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 place label may also take seconds; without it that old label 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. Lost? Call front_door.

Input Schema

NameRequiredDescriptionDefault
nameYes
recipeNooptional 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
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, open-world, non-idempotent, non-destructive creation tool. The description adds meaningful behavioral context beyond that: the trait is 'free public,' a refused recipe reports where reading stopped, and 'nothing is stored' on refusal, which discloses atomic validation failure.

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

Conciseness2/5

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

The purpose is front-loaded, but the rest is a long, semicolon-heavy wall of constraints that duplicates material the description itself points to in physics. For a three-parameter tool, this is poorly sized and hard to scan, even though much of the content is relevant.

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?

Given the complex recipe input, low schema coverage, and no output schema, the description is largely complete: it covers creation semantics, parameter constraints, validation behavior, and external references. It does not describe the successful return value, which leaves a minor gap for an agent invoking the tool.

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 description coverage is only 33%, but the description compensates well: it explains name uniqueness/normalization, description default and safe-character limit, and recipe semantics including null, array shorthand, action keys, wake key, and validation limits. Some recipe details remain dense or rely on external docs, but overall it adds substantial meaning beyond the schema.

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 description opens with a specific verb and resource: 'Coin a free public trait.' This is clear enough for an agent to know it creates a trait. It does not explicitly distinguish the tool from siblings such as invent_kind, revise_kind, or thing_edit, so it falls short of 5.

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

Usage Guidelines3/5

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

The description gives a prerequisite ('Read physics first') and an escape hatch ('Lost? Call front_door'), which implies when to consult supporting tools. However, it never states when to use coin_trait versus alternatives like invent_kind or revise_kind, nor when not to use it.

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.