Field Service Business Platform by Doing Work

agents_register

Preferred when you know the owner's email: type service_auth and login_hint. The reply's short fields come first: claim_attempt_token, user_code, claim_token, claim_page, then verification_uri. Use verification_uri only when its length matches verification_uri_length. If it was cut, build the link from claim_page and claim_attempt_token. Do not invent the host. Do not open claim_url alone. Do not register again when complete is missing and claim_token is present; call the claim endpoint once only if claim_attempt_token is missing. Scope omitted can create a shop. read_only cannot. type anonymous only when you do not yet have the email. identity_assertion is not accepted.

Input Schema

Name	Required	Description	Default
`type`	Yes
`scope`	No
`assertion`	No
`login_hint`	No
`client_name`	No
`assertion_type`	No

Output Schema

Name	Required	Description
`claim`	No
`claim_url`	Yes
`claim_token`	Yes	Secret. Keep it; you poll the token endpoint with it.
`registration_id`	Yes
`pre_claim_scopes`	Yes
`post_claim_scopes`	Yes
`registration_type`	Yes
`claim_token_expires`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedNov 6, 2026

addedOutput schema / properties / claim / properties / approval
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / claim / properties / authenticated
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / claim / 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 / properties / claim_page

Added value: +{
+  "description": "Page with no token. Not an approval link by itself.",
+  "type": "string"
+}

addedOutput schema / properties / claim / properties / next_step
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / claim / properties / persistence
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / claim / 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 / properties / verification_uri_length
```
Added value: +{
+  "type": "integer"
+}
```

changedOutput schema / properties / claim / 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"
+]

First observedNov 1, 2026

TDQS

C2.8/5.0

Behavior3/5

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

Without annotations, the description does disclose notable behavior: shop creation when scope is omitted, a duplicate-registration guard, claim-token conditions, and verification_uri truncation handling. However, it omits auth requirements and rate limits, and includes confusing guidance such as "identity_assertion is not accepted" despite the enum permitting it.

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

Conciseness2/5

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

The description is a dense run-on paragraph of operational instructions, not front-loaded with purpose. It jumps among response fields, claim flow, scope side effects, and type rules, making it hard to follow despite containing some useful content.

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

Completeness2/5

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

For a 6-parameter registration tool with no annotations, the description leaves several parameters unexplained and never clearly states the tool's overall purpose or authentication expectations. The output schema reduces the need to explain return values, yet the description spends much space on response-field handling instead of completing parameter and behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description only partially clarifies type and login_hint, mentions a scope side effect, and refers to read_only even though no such parameter exists. It leaves assertion, assertion_type, and client_name undocumented and contradicts the enum by rejecting identity_assertion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description never plainly states that this tool registers an agent; it opens with a usage condition ("Preferred when you know the owner's email") and then focuses on response fields and claim flow. The name and token references imply registration, but the purpose remains vague and is not clearly differentiated from agents_claim.

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?

It gives explicit type selection guidance (service_auth with login_hint, anonymous without email), when not to re-register, and when to call the claim endpoint. These are actionable conditions, though the prose is hard to parse and does not explicitly name agents_claim.

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

All Field Service Business Platform by Doing Work 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?