Skip to main content
Glama

create_key

Create a map key. Publishable (for a website): give the hostnames it may be used from; the returned publishable value goes in the page. Secret (for a server): the returned secret is shown once and must be stored by the human now. Workspace owner only.

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

Input Schema

NameRequiredDescriptionDefault
devNoPublishable keys only: also allow localhost and 127.0.0.1 on any port, for development.
kindYes"publishable" for a website (works only from the listed origins; the value goes in the page) or "secret" for a server (shown once, never in a browser).
nameYesA label, e.g. the site or app it is for.
originsNoPublishable keys only: hostnames the key may be used from, e.g. "example.com", "*.example.com", "localhost:5173", or a native app as "app:com.example.myapp" (its bundle id or package name). At most 50.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond annotations, it discloses two important behavioral facts: secret keys are shown once and must be stored immediately, and the operation is restricted to the workspace owner. These are exactly the kind of operational and auth details an agent needs for a security-sensitive mutation.

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

Conciseness5/5

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

The description is front-loaded with the core action, then efficiently covers the two key modes, the one-time secret handling, and the owner-only restriction. Every sentence carries useful information with no filler.

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 security-sensitive mutation with no output schema, it covers the essentials: mode selection, return-value handling for publishable and secret keys, and authorization scope. It does not mention duplicate-name behavior or error cases, but it is otherwise complete enough to call correctly.

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 100%, so the schema already documents kind, name, origins, and dev thoroughly. The description reinforces the kind distinction and origin usage but adds little parameter meaning beyond the schema and does not mention the dev parameter.

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: 'Create a map key.' The create/list/revoke/set-origins sibling verbs are clearly distinct, and the publishable vs. secret split further clarifies the tool's scope.

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 clear contextual guidance for choosing between a publishable key for a website and a secret key for a server. It does not explicitly name alternatives such as list_keys or explain when not to call create_key, so it falls short of a 5.

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