Skip to main content
Glama

Field Service Business Platform by Doing Work

agents_claim

auth.md claim. Pass your claim_token and the email of the shop owner who should claim you. You get a 6 digit user_code and a verification_uri: tell the person to open the link, sign in with that email and type the code. Then poll the token endpoint with grant_type urn:workos:agent-auth:grant-type:claim. Calling again with the same claim_token starts a fresh code and cancels the old one.

Input Schema

NameRequiredDescriptionDefault
emailYes
claim_tokenYes

Output Schema

NameRequiredDescriptionDefault
statusYes
expires_atYes
claim_attemptYes
registration_idYes
claim_attempt_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedOutput schema / properties / claim_attempt / properties / approval
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / claim_attempt / properties / authenticated
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / claim_attempt / properties / claim_attempt_token
      Added value: +{
      +  "description": "Short token. With claim_page it is the approval link. Never put user_code in that link.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / claim_attempt / properties / claim_page
      Added value: +{
      +  "description": "Page with no token. Not an approval link by itself.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / claim_attempt / properties / next_step
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / claim_attempt / properties / persistence
      Added value: +{
      +  "type": "string"
      +}
    • changedOutput schema / properties / claim_attempt / properties / verification_uri / description
      Previous value: -"Hosted claim page for the person to open."New value: +"Full approval link. Use it only when its length equals verification_uri_length."
    • addedOutput schema / properties / claim_attempt / properties / verification_uri_length
      Added value: +{
      +  "type": "integer"
      +}
    • changedOutput schema / properties / claim_attempt / required
      Previous value: -[
      -  "user_code",
      -  "expires_in",
      -  "verification_uri",
      -  "interval"
      -]New value: +[
      +  "approval",
      +  "authenticated",
      +  "persistence",
      +  "next_step",
      +  "claim_attempt_token",
      +  "user_code",
      +  "expires_in",
      +  "interval",
      +  "claim_page",
      +  "verification_uri_length",
      +  "verification_uri"
      +]
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden and does well: it explains the returned user_code and verification_uri, what the human must do, the subsequent token polling step, and the important side effect that reusing the same claim_token cancels the old code and issues a fresh one. It omits code expiration, error behavior, and permission requirements, keeping it from 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 description is appropriately sized and mostly front-loaded: purpose, parameters, output/instructions, next polling step, and idempotency note. The opening 'auth.md claim' is slightly cryptic, and the long grant_type string is heavy, but no sentence is wasted.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there are no annotations, no parameter descriptions in the schema, and an output schema exists, the description is sufficiently complete for an agent to execute the flow. It covers the human handoff and polling step, though it lacks details on code expiry, error cases, and where the token endpoint URL is defined.

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 description coverage is 0%, so the description must compensate for both parameters. It explains that claim_token is the caller's token and email identifies the shop owner who should claim the agent, and it additionally clarifies reuse semantics for claim_token. It does not explain where the claim_token comes from or any format constraints.

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?

The description clearly states that this tool initiates an agent claim flow: pass a claim_token and the shop owner's email, receive a user_code and verification_uri, and then poll the token endpoint. It is specific about the action and outcome, but it does not explicitly distinguish itself from sibling tools like agents_register or auth_oauth*.

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?

The flow implies when to use it—when an agent needs a shop owner to claim it—but there is no explicit guidance on when to choose this over agents_register or other auth tools. It gives operational context and a reuse caveat but no exclusions or named alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources