qURL

Update qURL Token

update_qurl_token

Instructions

Update one qURL token under a resource: expiration, label, access policy, max sessions, or session duration. Use this when you need to change a specific q_… token without changing sibling tokens or resource-level metadata. Use update_qurl instead for resource-level description/tags/custom-domain changes, and use revoke_qurl_token when the token should stop working entirely. Constraints: extend_by and expires_at are mutually exclusive; at least one token update field must be set. Returns the updated token summary.

Input Schema

Name	Required	Description
`label`	No	Human-readable label for this token
`qurl_id`	Yes	The qURL display ID (q_ prefix) to update.
`extend_by`	No	Duration to extend this token by (e.g., "24h", "7d"; 1m to 30d per call). Mutually exclusive with expires_at.
`expires_at`	No	Absolute token expiration timestamp (RFC 3339). Mutually exclusive with extend_by.
`resource_id`	Yes	The resource public key, CRID, or legacy r_ ID to update a specific qURL token under.
`max_sessions`	No	Maximum concurrent sessions for this token (0 = unlimited, max 1000)
`access_policy`	No	Replace the access policy for this token
`session_duration`	No	How long access lasts after clicking (e.g., "1h"; 1s to 24h). Empty string applies the parent resource cap when one is set.

Output Schema

Name	Required	Description	Default
`label`	No
`status`	Yes	Per-token status (wider than resource status — tokens may be consumed/expired independently)	unknown
`qurl_id`	Yes
`qurl_site`	No
`use_count`	No
`created_at`	No
`expires_at`	No
`max_sessions`	No
`one_time_use`	No
`access_policy`	No	Access control policy snapshot for this token
`session_duration`	No	Seconds of access granted after a successful resolve

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.2.2Oct 14, 2026

changedInput schema / properties / extend_by / description

Previous value: -"Duration to extend this token by (e.g., \"24h\", \"7d\"). Mutually exclusive with expires_at."New value: +"Duration to extend this token by (e.g., \"24h\", \"7d\"; 1m to 30d per call). Mutually exclusive with expires_at."

addedInput schema / properties / extend_by / maxLength
```
Added value: +32
```
removedInput schema / properties / extend_by / minLength
```
Removed value: -1
```

changedInput schema / properties / session_duration / description

Previous value: -"How long access lasts after clicking (e.g., \"1h\"). Empty string applies the parent resource cap when one is set."New value: +"How long access lasts after clicking (e.g., \"1h\"; 1s to 24h). Empty string applies the parent resource cap when one is set."

addedInput schema / properties / session_duration / maxLength
```
Added value: +32
```

Addedv0.2.1Sep 19, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the safety profile is covered. The description adds real behavioral context beyond them: the extend_by/expires_at mutual exclusion, the requirement that at least one update field be set, and the fact that the updated token summary is returned. It does not, however, disclose auth requirements, whether changes affect already-active sessions, or that access_policy is a wholesale replace (only the schema notes that).

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

Conciseness5/5

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

Three sentences, front-loaded: scope and updatable fields first, sibling routing second, hard constraints last. No sentence is redundant with another, and the constraints are bolded and compressed rather than prose-padded.

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 an 8-parameter mutation tool with nested objects, an output schema, and annotations covering safety hints, the description supplies what structured fields cannot: sibling routing and cross-field validation rules. Because an output schema exists, it correctly does not spend words explaining the return payload.

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 100%, so the baseline is 3 and the schema already documents each field including the extend_by/expires_at exclusivity. The description nevertheless contributes one genuine cross-parameter constraint not present in the schema — 'at least one token update field must be set' — which is exactly the kind of validation rule that prevents a failed call.

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?

Opens with a specific verb+resource ('Update one qURL token under a resource') and enumerates exactly which fields can change (expiration, label, access policy, max sessions, session duration). It explicitly names the sibling tools it is not (update_qurl, revoke_qurl_token) and the token-scoped boundary, so an agent can distinguish it from the resource-level and revoke operations without opening a 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?

States the selection condition ('change a specific q_… token without changing sibling tokens or resource-level metadata') and then routes to the two competing alternatives by name with the condition that selects each: update_qurl for description/tags/custom-domain, revoke_qurl_token when the token should stop working. Nothing is left to inference.

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

Deploy Server