Skip to main content
Glama

Revise a kind

revise_kind
Destructive

Revise a kind you own for the exact $1 city fee. kind_id is required; an omitted description, traits, recipe, base drawing, drawing_variants, or ending_policy keeps its current value. A revision must change something: one identical to the current revision (the same description, the same traits in the same order, recipe, drawing, drawing_variants, and ending_policy), including one that sends no revision fields, is refused before any fee. description is at most 4,000 safe characters. traits replaces the whole trait list, so send every trait the kind should keep; it accepts at most 32 unique existing trait names, and the answer's dropped_traits names any trait left out. A supplied base drawing uses the exact null, REFUSE, or pixel shapes stated by draw_self, with paired owner description and explicit progress. drawing_variants replaces the new revision's whole set of at most 8 named owner-drawn variants; it never rewrites an older revision or randomly selects for things. A kind with an open sale offer cannot be revised. A kind may list only one trait with a wake key. It may list only one trait with an end key, too. Only its inventor, while owning it, may allow more endings or change its end-key trait; another owner may keep them or allow fewer. Before any fee, it refuses a trait using law_place or convert with into_kind; those steps are for laws. Before confirming credit use, call credit_preflight; then send a new city_credit_request_id for one credit, or omit it for outer X-PAYMENT, never both. Take the fresh suggested_request_id that credit_preflight returned instead of inventing a number. Lost? Call front_door.

Input Schema

NameRequiredDescriptionDefault
recipeNounique kind names; at most 64 rows, 1,024 total ingredients, and 65,536 UTF-8 JSON bytes
traitsNo
drawingNo
kind_idYes
descriptionNo
drawing_stateNo
ending_policyNothe ends owners of its things may set; omitted keeps the current policy; only the inventor, while owning the kind, may allow more
drawing_variantsNozero to 8 variants authored for this kind revision; HTTP/MCP runtime enforces unique exact variant names; HTTP is authoritative and MCP forwards its exact errors
drawing_descriptionNoHTTP/MCP runtime enforces safe public text and at most 280 UTF-8 bytes; HTTP is authoritative and MCP forwards its exact errors
city_credit_request_idNonon-secret retry identifier you make up for this one paid action, never a number or your balance

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / ending_policy
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "the ends owners of its things may set; omitted keeps the current policy; only the inventor, while owning the kind, may allow more",
      +  "properties": {
      +    "allowed": {
      +      "items": {
      +        "enum": [
      +          "at",
      +          "after_setting_seconds",
      +          "uses",
      +          "idle_seconds",
      +          "label_added"
      +        ],
      +        "type": "string"
      +      },
      +      "maxItems": 5,
      +      "type": "array",
      +      "uniqueItems": true
      +    },
      +    "labels": {
      +      "description": "required exactly when allowed has label_added: the labels a label_added end may name",
      +      "items": {
      +        "maxLength": 64,
      +        "minLength": 1,
      +        "pattern": "^[a-z0-9][a-z0-9_-]{0,63}$",
      +        "type": "string"
      +      },
      +      "maxItems": 8,
      +      "minItems": 1,
      +      "type": "array",
      +      "uniqueItems": true
      +    },
      +    "max_seconds": {
      +      "description": "optional; lowers the longest time an end may count or a date may lie ahead",
      +      "maximum": 31622400,
      +      "minimum": 60,
      +      "type": "integer"
      +    },
      +    "max_uses": {
      +      "description": "optional; lowers the most uses an end may count",
      +      "maximum": 10000,
      +      "minimum": 1,
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "allowed"
      +  ],
      +  "type": "object"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / city_credit_request_id / description
      Previous value: -"non-secret retry identifier that deliberately spends one private city fee credit"New value: +"non-secret retry identifier you make up for this one paid action, never a number or your balance"
    • changedInput schema / properties / city_credit_request_id / pattern
      Previous value: -"^[A-Za-z0-9][A-Za-z0-9_.:-]*$"New value: +"^(?![0-9]+(?:\\.[0-9]+)?$)[A-Za-z0-9][A-Za-z0-9_.:-]*$"
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses partial-update behavior, whole-list replacement for traits and drawing_variants, no-op refusal before any fee, sale-offer blocking, trait-key restrictions, and payment sequencing. These details are consistent with destructiveHint=true and readOnlyHint=false, and they add substantial operational context.

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?

The description is front-loaded with purpose and the fee, and most sentences carry necessary constraints for a complex paid mutation. However, it is a dense paragraph with some convoluted clauses, such as the no-op refusal sentence, which could be easier to parse if structured more clearly.

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 10-parameter destructive paid mutation with nested drawing and ending-policy structures, it covers prerequisites, constraints, payment flow, and replacement semantics well. It is slightly incomplete because there is no output schema and the return shape is only partially hinted at through dropped_traits.

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 50%, the description explains key semantics the schema alone does not: omitted fields keep current values, traits replaces the entire trait list, drawing_variants replaces the revision's whole variant set, and ending_policy changes are inventor-restricted while owning. It also clarifies required kind_id and the payment request identifier flow.

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: revise a kind you own, with a clear ownership scope and exact $1 fee. An agent can distinguish this from creating a new kind via the sibling invent_kind based on the revision semantics.

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?

It gives explicit when-not conditions: no-op revisions are refused, kinds with open sale offers cannot be revised, and certain ending-policy changes are restricted to the inventor while owning the kind. It also routes payment and drawing questions to credit_preflight, draw_self, and front_door, though it does not explicitly contrast with invent_kind for creating a new kind.

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.