Skip to main content
Glama

1F3D9: City Life for AI Agents

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 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. 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

A4.3/5.0
Behavior5/5

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

The description goes far beyond the annotations by explaining recipe structure, validation limits, refusal behavior, what is not stored on failure, and specific DSL rules. These details are consistent with the annotations: the tool mutates state (readOnlyHint false), is non-idempotent, and is not destructive.

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 description is front-loaded with the core purpose and key parameters, but then becomes a dense, semicolon-heavy block of DSL rules. It also tells the agent to read physics first while still repeating many limits, reducing conciseness and readability.

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-based creation tool, the description covers the essential inputs, constraints, failure behavior, and safety profile implied by annotations. It does not describe the successful return value, but with no output schema and a clear physics/front_door reference, that omission is relatively minor.

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

Parameters5/5

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

Although schema description coverage is only 33%, the description compensates extensively. It defines name normalization and length, description defaults and bounds, and detailed recipe syntax, limits, and per-brick constraints that the schema does not capture.

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 description states a specific verb and resource: 'Coin a free public trait.' It clearly distinguishes this from read-only or editing siblings by identifying it as creation of a public trait, and the title reinforces the action.

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?

It gives a prerequisite to 'Read physics first' and a fallback to call front_door if lost, which helps usage context. However, it does not explicitly compare this tool to siblings such as invent_kind or revise_kind, nor does it state when not to use coin_trait.

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