Replo

Create API key

create_api_key

Destructive

Create a Git API key with repository scopes and choose its type. type user (the default) reaches every project you can access, follows your live workspace role for pushes and must expire (1–366 days); use it for a coding agent working for you, such as Codex or Claude Code. type project reaches only the projects in projectIds (one or more you can manage) and may never expire; use it for CI or automation. Returns the secret once and structured Git host/username. Follow the local-development skill to store it through stdin and verify credential read-back; never print, commit, or repeat the secret. Site objects from list_sites include clone_url. Creating a user key beyond ten live keys revokes the least recently used one (unused keys first).

Input Schema

Name	Required	Description	Default
`name`	Yes
`type`	No	Which access the key carries. user (default): every project you can access, following your live workspace role; pick it for a coding agent working on your behalf, such as Codex or Claude Code. project: only the projects in projectIds; pick it for CI or automation that should touch named projects and nothing else.	user
`scopes`	Yes	Repository scopes: repo.read to clone and pull, add repo.write to push.
`projectIds`	Yes	Projects a project key can reach; you must be able to manage each one. Required for type project. Null for type user, which reaches every project you can access.
`workspaceId`	Yes
`expiresInDays`	Yes	Days until the key expires (1–366). User keys must expire; null makes a project key last until revoked.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 31, 2026

removedInput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / projectIds / anyOf

Previous value: -[
-  {
-    "items": {
-      "format": "uuid",
-      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
-      "type": "string"
-    },
-    "maxItems": 100,
-    "minItems": 1,
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "format": "uuid",
+      "type": "string"
+    },
+    "maxItems": 100,
+    "minItems": 1,
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / workspaceId / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changed9 schema fields changedOct 30, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / expiresInDays

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 366,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Days until the key expires (1–366). User keys must expire; null makes a project key last until revoked."
+}

removedInput schema / properties / projectId

Removed value: -{
-  "format": "uuid",
-  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
-  "type": "string"
-}

addedInput schema / properties / projectIds

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "format": "uuid",
+        "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+        "type": "string"
+      },
+      "maxItems": 100,
+      "minItems": 1,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Projects a project key can reach; you must be able to manage each one. Required for type project. Null for type user, which reaches every project you can access."
+}

removedInput schema / properties / scopes / default
```
Removed value: -[
-  "repo.read"
-]
```

addedInput schema / properties / scopes / description

Added value: +"Repository scopes: repo.read to clone and pull, add repo.write to push."

addedInput schema / properties / type

Added value: +{
+  "default": "user",
+  "description": "Which access the key carries. user (default): every project you can access, following your live workspace role; pick it for a coding agent working on your behalf, such as Codex or Claude Code. project: only the projects in projectIds; pick it for CI or automation that should touch named projects and nothing else.",
+  "enum": [
+    "user",
+    "project"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "workspaceId",
-  "projectId",
-  "name"
-]New value: +[
+  "workspaceId",
+  "name",
+  "projectIds",
+  "scopes",
+  "expiresInDays"
+]

First observedOct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, readOnlyHint=false): it discloses that the secret is returned exactly once, that creating a user key beyond ten live keys revokes the least-recently-used key (unused first), and that the secret must be handled via stdin and never printed or committed. These are non-obvious side effects and handling requirements an agent could not infer.

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 the type distinction, then layers side effects and secret-handling rules. Dense but each sentence carries distinct information, though the skill-pointer and list_sites/clone_url remark sit slightly apart from the main flow.

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 supplies the return shape (secret once plus structured Git host/username) and the destructive side effect of key revocation. Combined with the per-type constraints, an agent has everything needed to call this correctly and safely.

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 67% and the description largely restates what the schema already says about type, projectIds, and expiresInDays. It adds the useful cross-field rule (user keys must expire, project keys may never expire) but leaves name and workspaceId unaddressed, so it only partially compensates for the coverage gap.

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 and resource ('Create a Git API key') and immediately distinguishes the two modes (user vs project) that define the tool's behavior. Nothing in the sibling list does anything similar, so an agent can identify it without ambiguity.

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 routing guidance: user type for a coding agent acting on your behalf (Codex/Claude Code), project type for CI or automation touching named projects only. It also names the constraint that projectIds must be projects you can manage and that user keys must expire, so the selection criteria are fully spelled out.

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

All Replo tools Inspect

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

Need Help?