Skip to main content
Glama

EchoRelay

by dev.echorelay
OverviewDiscussionsAdmin

create_project_token

Mint a PROJECT-scoped management token (er_mcp_) for MCP and REST; it cannot authenticate relay traffic. Use it after create_project to configure a fresh project, or for any project you already own. Attenuated by design: the scopes must be a subset of THIS management token's own grant (read is always included), expiry is mandatory (1–90 days, default 30, never "never"), and the minted management token (being project-scoped) can never mint management tokens itself. spend is human-granted only: no management token, of any scope, can mint one carrying it. Mint a spend-scoped token from the project's panel instead. Requires an ACCOUNT-scoped management token and the config scope. Returns the plaintext exactly once; only its hash is stored.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesThe slug of a project you own.
labelYesHuman-readable management token label (1–100 chars).
scopesNoScopes for the minted management token: must be a subset of this management token's own scopes. `read` is always granted. `spend` and the legacy `billing` scope are never mintable here (panel-only). Default: read + config.
expiresInDaysNoDays until the minted management token expires. Default 30. API-minted management tokens always expire.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / expiresInDays / description
      Previous value: -"Days until the minted token expires. Default 30. API-minted tokens always expire."New value: +"Days until the minted management token expires. Default 30. API-minted management tokens always expire."
    • changedInput schema / properties / label / description
      Previous value: -"Human-readable token label (1–100 chars)."New value: +"Human-readable management token label (1–100 chars)."
    • changedInput schema / properties / scopes / description
      Previous value: -"Scopes for the minted token — must be a subset of this token's own scopes. `read` is always granted. `spend` and the legacy `billing` scope are never mintable here — panel-only. Default: read + config."New value: +"Scopes for the minted management token: must be a subset of this management token's own scopes. `read` is always granted. `spend` and the legacy `billing` scope are never mintable here (panel-only). Default: read + config."
  2. Changed2 schema fields changed
    • changedInput schema / properties / scopes / description
      Previous value: -"Scopes for the minted token — must be a subset of this token's own scopes. `read` is always granted. Default: read + config."New value: +"Scopes for the minted token — must be a subset of this token's own scopes. `read` is always granted. `spend` and the legacy `billing` scope are never mintable here — panel-only. Default: read + config."
    • changedInput schema / properties / scopes / items / enum
      Previous value: -[
-  "read",
-  "config",
-  "mint:keys",
-  "manage:billing",
-  "spend",
-  "billing"
-]New value: +[
+  "read",
+  "config",
+  "mint:keys",
+  "manage:billing"
+]
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only indicate non-read, non-destructive behavior. The description adds critical behavioral detail beyond that: minted tokens are attenuated, scopes must be a subset, expiry is mandatory, minted project-scoped tokens can never mint management tokens, and the plaintext is returned exactly once with only a hash stored. This goes well beyond what the annotations convey.

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 dense but well-structured: purpose first, then usage guidance, then constraints, then credential-handling behavior. Every sentence carries operational weight, and the security-relevant details justify the length.

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?

With no output schema, the description correctly discloses the critical return behavior ('Returns the plaintext exactly once; only its hash is stored'). It also covers prerequisites, scoping constraints, alternatives, and when-not-to-use, making it complete for correct invocation.

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?

The schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds meaningful semantic context: scopes are always subsetted, read is always included, spend is human-granted only, and 'never never' expiry is disallowed. This adds value beyond the schema's field-level descriptions.

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 ('Mint') and resource ('PROJECT-scoped management token') with a clear scope boundary: it works for MCP and REST but cannot authenticate relay traffic. This distinguishes it from siblings like create_api_key, list_project_tokens, and revoke_project_token without needing to open their schemas.

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?

It explicitly says when to use the tool ('after create_project to configure a fresh project, or for any project you already own') and gives a when-not instruction with an alternative ('Mint a spend-scoped token from the project's panel instead'). It also states the required calling context: an ACCOUNT-scoped management token with the config scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All EchoRelay toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources