SubmitraX

Generate workspace API token

generate_workspace_api_token

Generate (or reset) a long-lived API token (sk_...) scoped to a single workspace, for use with public API integrations.

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": {
      "id": "<id>"
    },
    "name": "generate_workspace_api_token"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Workspace ID

Output Schema

Name	Required	Description	Default
`data`	Yes	Response body returned by the SubmitraX API

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 29, 2026

addedInput schema / properties / id / description
```
Added value: +"Workspace ID"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "description": "Response body returned by the SubmitraX API"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

First observedSep 28, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds meaningful context beyond those: the token is long-lived, has a recognizable sk_ prefix, is workspace-scoped, and 'or reset' signals that a prior token may be replaced/invalidated. It still does not say whether the old token is revoked or where the secret is returned.

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?

A single front-loaded sentence that delivers verb, resource, scope, token shape, and lifecycle note without any filler. Nothing to trim.

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?

With an output schema present, return details need not be explained, and the description covers scope and lifecycle. The remaining gap is authorization requirements and whether existing tokens are invalidated on reset — useful for a non-idempotent, open-world mutation, but not fatal.

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?

Only one parameter exists and the schema documents it at 100% coverage ('Workspace ID'). The description's 'scoped to a single workspace' corroborates the parameter's meaning but adds no syntax or format detail beyond the schema. Baseline 3 applies when the schema already carries the parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Generate/reset), resource (API token), naming convention (sk_...), token lifetime (long-lived), and scope (single workspace). No sibling in the list performs a similar token action, so differentiation is not needed. Clear and specific, though not explicitly contrasted with any alternative.

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?

Describes the intended purpose (public API integrations) and notes it can reset an existing token, which implies a rotation use case. However, it does not state prerequisites (e.g., required role/permissions) or when an agent should prefer resetting over other auth flows such as login or set_auth_token.

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

All SubmitraX tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?