AnalyticsProof

Create a one-time CI key claim

create_ci_key_claim

Create a one-time CI key claim (permission: admin)

Call this only as the step right before you run its command, and never pass the claim anywhere else. A one-time claim for an edit key of the saved test’s project, and the commands that redeem it straight into the CI secret store (GitHub Actions secret, GitLab CI/CD variable, Bitbucket repository variable). The answer holds no key: the key is minted when a command redeems the claim, once, within 10 minutes, and is never printed. Run the matching command in the repository’s shell right away. If it fails, revoke the key with DELETE /keys/{keyId} (MCP revoke_api_key). An agent connection needs editor or above on the project (as for POST /keys); the project plan must include the API. Revoking the calling key or connection before the redemption voids the claim. A foreign or unknown target answers 404. Idempotency-Key is ignored: each call is a new claim.

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": {
      "targetId": "<targetId>",
      "name": "<name>"
    },
    "name": "create_ci_key_claim"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	The key name shown in the API key list, e.g. `CI · github.com/acme/web`.
`targetId`	Yes	The saved test the CI job gates; the key is for its project.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds a lot beyond the annotations: the claim is single-use, expires in 10 minutes, the key is never printed, the response contains no key, and Idempotency-Key is ignored. It also states authorization prerequisites (editor or above on the project, plan must include the API), that revoking the calling key voids the claim, and that unknown targets 404.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The action and safety constraint are front-loaded, but the middle section drifts into a run-on sentence with a sentence fragment ("A one-time claim for an `edit` key of the saved test's project, and the commands that redeem it..."). The content mostly earns its place, yet the packaging makes it slower to scan than it needs to be.

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 two-parameter mutation tool with no output schema, the description covers lifecycle (expiry, single use), response contents, failure handling, permissions, and error behavior. Nothing an agent needs in order to call it correctly and safely is missing.

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: targetId is the saved test being gated and the minted key belongs to that test's project, which the schema field description only partly conveys. The `name` parameter is left to the schema, which already carries a usage example.

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?

Names a specific verb+resource ("Create a one-time CI key claim") and immediately scopes it: a claim for an `edit` key of the saved test's project, redeemed into a CI secret store. That distinguishes it clearly from list_api_keys, revoke_api_key, and get_ci_recipe without opening any schema.

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?

Gives explicit when-to-use ("only as the step right before you run its command"), an explicit prohibition ("never pass the claim anywhere else"), timing pressure ("Run the matching command in the repository's shell right away"), and a named fallback (revoke_api_key) if the redemption fails.

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

All AnalyticsProof 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?