Skip to main content
Glama

Gluecron

by com.gluecron
OverviewDiscussionsAdmin

gluecron_create_repo_token

Mint a fine-grained repository token (gcft_…) for ONE repository and return it once. It authenticates the REST API (/api/v2 and the GitHub-compatible /api/v3), git over HTTPS and the container registry (images under owner/repo, by contents) for that repository only. permissions sets none/read/write for contents, issues, pull_requests, statuses and actions (admin and settings are never grantable); expires_in is optional: omit it (or "never") for no expiration, or give seconds or "30m", "12h", "7d", "1y" (min 5 minutes, max 1 year). Effective access is always held to YOUR current access to the repo, re-checked on every use, and branch protection applies as it does to you. Needs 'repo' scope. Audit-logged. Returns {id, name, repository, permissions, expiresAt, tokenPrefix, token}.

Input Schema

NameRequiredDescriptionDefault
nameYesWhere the token will be used, e.g. 'gatetest deploy box'
repoYesRepo name
ownerYesRepo owner — username or organisation slug
expires_inNoOptional lifetime: "30m" / "12h" / "7d" / "1y", or a number of seconds (5 minutes to 1 year). Omit, or "never", for no expiration.
permissionsYesObject of level per permission — keys contents, issues, pull_requests, statuses, actions; values none | read | write; omitted keys are none; at least one must be read or write. Example: {"actions": "read"}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / expires_in / description
      Previous value: -"Required lifetime: \"30m\" / \"12h\" / \"7d\" / \"1y\", or a number of seconds (5 minutes to 1 year)."New value: +"Optional lifetime: \"30m\" / \"12h\" / \"7d\" / \"1y\", or a number of seconds (5 minutes to 1 year). Omit, or \"never\", for no expiration."
    • changedInput schema / required
      Previous value: -[
-  "owner",
-  "repo",
-  "name",
-  "permissions",
-  "expires_in"
-]New value: +[
+  "owner",
+  "repo",
+  "name",
+  "permissions"
+]
  2. Added

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: discloses exactly what the token authenticates (REST v2/v3, git over HTTPS, container registry), that effective access is capped by the caller's access and re-checked on every use, that branch protection applies, that admin/settings are never grantable, that it requires 'repo' scope, and that it is audit-logged.

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-loads the purpose and is information-dense with no filler sentences. It is a single dense paragraph covering many facets, which slightly reduces scannability, but nearly every clause carries operational value.

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?

For a mutation tool with no output schema and a nested-object parameter, it covers auth requirements, side effects (audit log, one-time return), access limits, expiration semantics, and even enumerates the return shape, leaving nothing an agent needs in order to invoke it correctly.

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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning beyond the schema: it states that admin and settings are never grantable, that omitted permission keys default to none with at least one read/write required, and it spells out the expires_in min/max and accepted formats.

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: 'Mint a fine-grained repository token (`gcft_…`) for ONE repository and return it once.' The scope ('for that repository only', 'return it once') clearly distinguishes it from siblings like create_deploy_token, create_runner_registration_token, and list_repo_tokens.

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?

Provides strong operational context (one-repo scope, what the token authenticates, expiration options, 'repo' scope requirement), which implies when the tool is appropriate. However, it never explicitly names an alternative token tool (e.g. create_deploy_token) or states an exclusion, so it stops short of full when/when-not guidance.

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

All Gluecron 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