Skip to main content
Glama

Gluecron

by com.gluecron
OverviewDiscussionsAdmin

gluecron_create_runner_registration_token

Create a one-time CI runner registration token for an owner (your username, an org you own or admin, or 'platform' as a site admin). A runner started with RUNNER_REGISTRATION_TOKEN= registers once and gets its own long-lived credential; that owner's CI then runs on it. Expires in an hour. Pass exclusive: true for a label-only runner (a Mac for Xcode, a GPU box): it takes only jobs whose runs-on names its labels (e.g. [self-hosted, macos, xcode]), never runs-on: self / ubuntu-*, and the account keeps its shared lane; repositories narrows it to some of the owner's repositories. Both are fixed for the runner's life. Returns {owner, token, expiresAt, exclusive, repositoryIds, gluecronUrl}.

Input Schema

NameRequiredDescriptionDefault
ownerYesUsername, org slug, or 'platform'
labelsNoComma-separated labels the runner gets in addition to its own (e.g. gpu,arm64)
exclusiveNoLabel-only runner (default false): offered only jobs whose runs-on labels it all has, never the account's default lane. Fixed at registration; a heartbeat cannot change it.
repositoriesNoExclusive runners only: comma-separated repository names of this owner it serves (default: all of them)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / exclusive
      Added value: +{
+  "description": "Label-only runner (default false): offered only jobs whose runs-on labels it all has, never the account's default lane. Fixed at registration; a heartbeat cannot change it.",
+  "type": "boolean"
+}
    • addedInput schema / properties / repositories
      Added value: +{
+  "description": "Exclusive runners only: comma-separated repository names of this owner it serves (default: all of them)",
+  "type": "string"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare non-readonly/non-destructive; the description adds real behavioral context beyond them: one-time token, one-hour expiry, runner obtains its own long-lived credential, and that exclusive/repositories are fixed for the runner's life. It also lists the return shape despite no output schema.

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, then semantics, then return value. Dense but each clause carries useful information; slightly long-sentence phrasing, but appropriate for a tool with non-obvious fixed-at-registration behavior.

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?

Given a mutation tool with no output schema, the description covers expiry, one-time nature, credential lifetime, flag effects, and the return fields — everything an agent needs to call 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 elaborates meaningfully beyond the schema: 'platform' as site-admin owner, exclusive runners never take runs-on: self/ubuntu-* and keep the account's shared lane, and repositories narrowing. This clarifies the effect of the flags, not just their types.

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 one-time CI runner registration token) and immediately distinguishes it from sibling token/runner tools by describing the one-time register-then-long-lived-credential flow. An agent can tell exactly what it produces.

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?

Explains the usage context clearly (a runner started with RUNNER_REGISTRATION_TOKEN registers once), and details when to use exclusive vs default and when to use repositories. It doesn't explicitly name a sibling alternative to avoid, but the scenario guidance is strong.

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