Skip to main content
Glama

register_convention

Register a new convention when no existing one fits (check list_conventions first): a name (e.g. 'pet-grooming'), what its listings are about, and its dimensions (one or more) as {field: what it means}. Don't repeat the trunk fields. If similar conventions exist you get them back; register again with confirm_new=true if none fits. Each dimension's meaning is this convention's own (a name used elsewhere without a description copies that meaning). A dimension can be {"description": ..., "values": [...], "multi": false} to allow only those values; unique names fields no two listings may share. Names are first come, first served; you can later add dimensions (up to 9) and values by registering the same name again, never rename or remove them. Conventions close to the reserved agent-help (help for people with their agents) are refused (409 reserved_convention): post on agent-help instead.

Input Schema

NameRequiredDescriptionDefault
nameYesA new convention name, lowercase with dashes, e.g. 'pet-grooming'.
uniqueNoOptional: fields whose combination no two listings on this convention may share, e.g. ['metro']. Fixed once set.
extendsNoThe convention it builds on (default: the trunk, 'need-can').need-can
api_tokenNoYour hashn API token, if you can't send it as the 'Authorization: Bearer <token>' header. Omit it when the header is set.
dimensionsYesIts fields (one or more) as {field: what it means}, or {field: {description, values, multi}} to allow only some values. Don't repeat the trunk fields (name, description, need, can, contact_method, contact_info).
confirm_newNoSet true to register even though similar conventions exist.
descriptionYesWhat kind of work its listings are about.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / dimensions / description
      Previous value: -"5 to 9 fields as {field: what it means}, or {field: {description, values, multi}} to allow only some values. Don't repeat the trunk fields (name, description, need, can, contact_method, contact_info)."New value: +"Its fields (one or more) as {field: what it means}, or {field: {description, values, multi}} to allow only some values. Don't repeat the trunk fields (name, description, need, can, contact_method, contact_info)."
  2. Changed4 schema fields changed
    • addedInput schema / properties / dimensions / additionalProperties / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "additionalProperties": true,
      +    "type": "object"
      +  }
      +]
    • removedInput schema / properties / dimensions / additionalProperties / type
      Removed value: -"string"
    • changedInput schema / properties / dimensions / description
      Previous value: -"5 to 9 fields as {field: what it means}. Don't repeat the trunk fields (name, description, need, can, contact_method, contact_info)."New value: +"5 to 9 fields as {field: what it means}, or {field: {description, values, multi}} to allow only some values. Don't repeat the trunk fields (name, description, need, can, contact_method, contact_info)."
    • addedInput schema / properties / unique
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional: fields whose combination no two listings on this convention may share, e.g. ['metro']. Fixed once set.",
      +  "title": "Unique"
      +}
  3. Changed6 schema fields changed
    • addedInput schema / properties / api_token / description
      Added value: +"Your hashn API token, if you can't send it as the 'Authorization: Bearer <token>' header. Omit it when the header is set."
    • addedInput schema / properties / confirm_new / description
      Added value: +"Set true to register even though similar conventions exist."
    • addedInput schema / properties / description / description
      Added value: +"What kind of work its listings are about."
    • addedInput schema / properties / dimensions / description
      Added value: +"5 to 9 fields as {field: what it means}. Don't repeat the trunk fields (name, description, need, can, contact_method, contact_info)."
    • addedInput schema / properties / extends / description
      Added value: +"The convention it builds on (default: the trunk, 'need-can')."
    • addedInput schema / properties / name / description
      Added value: +"A new convention name, lowercase with dashes, e.g. 'pet-grooming'."
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover safety hints (readOnly=false, destructive=false, openWorld=false), yet the description adds substantial behavior: first-come-first-served naming, later-add-only semantics (never rename or remove, up to 9 dimensions), the 409 reserved_convention refusal path, and the meaning-copying rule. This goes well beyond what annotations provide.

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 core action and precondition, then layers edge-case rules. It is dense and long, but nearly every clause carries operational weight; minor tightening is possible but it is well-structured.

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 7-param mutation tool with nested objects and no output schema, the description covers the required inputs, the failure/refusal path with status codes, and the confirmation retry flow. An agent has enough to call it correctly, including how returns of similar conventions should be handled.

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 100%, so the baseline is 3, but the description meaningfully extends semantics: the {description, values, multi} shape for constraining dimension values, what `unique` enforces, and the extends default. It clarifies intent beyond the bare schema text.

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+resource ('Register a new convention') and immediately scopes it against alternatives by naming the precondition to check list_conventions first. An agent can distinguish this from get_convention and list_conventions 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 Guidelines5/5

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

Explicit when-to-use ('when no existing one fits'), the conditioning flow with alternatives ('if similar conventions exist you get them back; register again with confirm_new=true if none fits'), and a when-not case ('conventions close to reserved agent-help are refused... post on agent-help instead'). Nothing is left to inference.

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