Skip to main content
Glama
Sign In

TaskLite

by net.tasklite
OverviewDiscussionsAdmin

create_app_api_key

Create an API key for an app. SECURITY: the key must live server-side only (env var, Next.js API routes), never in browser code. If the app has its own users, the server also sends X-App-User: <user id> with the key so per-user endpoints know who is acting.

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": {
      "appId": "<appId>"
    },
    "name": "create_app_api_key"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoHuman-readable name
appIdYesApp id or slug (from list_apps / create_app)
scopesNoPermissions on the key: "read", "write", "email", "ai". Omit to match the app: write when any endpoint accepts POST, PATCH or DELETE. Sending email from the app server (POST /apps/<slug>/api/_email/send) needs the key to include "email" or "write"; a read-only key is refused with 403 APP_KEY_SCOPE_REQUIRED. Running the app's AI actions from its server (POST /apps/<slug>/api/_ai/v1/run, see configure_app_settings ai) needs "ai"; "write" does not include it.
organizationIdNoOrganization id; defaults to the credential organization when omitted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / scopes / description
      Previous value: -"Permissions on the key: \"read\", \"write\", \"email\". Omit to match the app: write when any endpoint accepts POST, PATCH or DELETE. Sending email from the app server (POST /apps/<slug>/api/_email/send) needs the key to include \"email\" or \"write\"; a read-only key is refused with 403 APP_KEY_SCOPE_REQUIRED."New value: +"Permissions on the key: \"read\", \"write\", \"email\", \"ai\". Omit to match the app: write when any endpoint accepts POST, PATCH or DELETE. Sending email from the app server (POST /apps/<slug>/api/_email/send) needs the key to include \"email\" or \"write\"; a read-only key is refused with 403 APP_KEY_SCOPE_REQUIRED. Running the app's AI actions from its server (POST /apps/<slug>/api/_ai/v1/run, see configure_app_settings ai) needs \"ai\"; \"write\" does not include it."
    • changedInput schema / properties / scopes / items / enum
      Previous value: -[
-  "read",
-  "write",
-  "email"
-]New value: +[
+  "read",
+  "write",
+  "email",
+  "ai"
+]
  2. Changed2 schema fields changed
    • changedInput schema / properties / scopes / description
      Previous value: -"Permissions recorded on the key: [\"read\"] or [\"read\",\"write\"]. Omit to match the app: write when any endpoint accepts POST, PATCH or DELETE."New value: +"Permissions on the key: \"read\", \"write\", \"email\". Omit to match the app: write when any endpoint accepts POST, PATCH or DELETE. Sending email from the app server (POST /apps/<slug>/api/_email/send) needs the key to include \"email\" or \"write\"; a read-only key is refused with 403 APP_KEY_SCOPE_REQUIRED."
    • changedInput schema / properties / scopes / items / enum
      Previous value: -[
-  "read",
-  "write"
-]New value: +[
+  "read",
+  "write",
+  "email"
+]
  3. Changed1 schema field changed
    • addedInput schema / properties / scopes
      Added value: +{
+  "description": "Permissions recorded on the key: [\"read\"] or [\"read\",\"write\"]. Omit to match the app: write when any endpoint accepts POST, PATCH or DELETE.",
+  "items": {
+    "enum": [
+      "read",
+      "write"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
  4. Changed3 schema fields changed
    • addedInput schema / properties / appId / description
      Added value: +"App id or slug (from list_apps / create_app)"
    • addedInput schema / properties / name / description
      Added value: +"Human-readable name"
    • addedInput schema / properties / organizationId / description
      Added value: +"Organization id; defaults to the credential organization when omitted"
  5. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only mark this as a non-read-only, non-destructive, non-idempotent write. The description adds real behavioral context beyond that: keys are secrets that must be server-side, and requests may carry an X-App-User header so per-user endpoints know the actor. It omits whether the secret is returned only once and whether keys can be revoked, which would have made this a 5.

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 core action is front-loaded in one short sentence, followed by two tightly scoped notes. The security sentence is justified, but the header sentence is a bit tangential to the act of creating a key.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 should say what comes back (the key value, and whether it is shown once). It also never states that the key belongs to the organization credential or what happens on duplicate names, leaving gaps for a credential-issuing mutation.

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 description coverage is 100% and the scopes enum semantics (email vs ai vs write) are fully documented in the schema itself. The description only mentions the app implicitly via the header example and adds no syntax or format detail for name, appId, or organizationId, so baseline 3 applies.

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 and resource ('Create an API key for an app') in the first clause. It is unambiguous about what is produced, though it never contrasts itself with neighboring tools such as configure_external_access or create_app_invite, which also touch app access.

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?

Usage is implied (you need an app-level credential), and the per-user section hints at when the app has its own users, but there is no explicit 'use this instead of X' or prerequisite guidance for scope selection beyond what the schema already says.

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

All TaskLite toolsInspect
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