qURL

Manage private CRID access

manage_crid_access

Destructive

Control publisher access for a CRID resource by configuring policies, sending or resending email invites, listing and revoking invites or grants, and approving or denying access requests.

Instructions

Publisher access control. Invite takes only action, resource_id and email; omit expected_version, approval and policy. Report the exact invited email addresses without shortening them. Check every page of list_invitations before claiming nobody else was invited. If listing is denied, report the send receipts and say the list is unconfirmed; do not resend. Accepted delivery does not prove enrollment. Configure the next policy version, send or resend an email invitation, list invitations or consumer grants, approve or deny a request, approve a credential with id new, or revoke access. Read the current version before a decision; configuring the first policy on an existing private resource uses expected_version 0. For approve, put expected_version inside approval; zero is allowed only for id new. Existing requests use the listed decision id and version without credential fields. A six-digit code alone never authorizes approval on a resource with consumer_access. Ask which listed request the user wants to approve (the verified email for review); keys needs the intended public credential and contract needs a trusted entitlement receipt. Wait for that instruction. After an uncertain invite result, list invitations before retrying. Invite-only access has no consumer requests. Contract approval requires a trusted publisher entitlement receipt and expiry, not an unverified payment claim. A removal is complete only when session_cleanup is complete; retry the same removal/version while pending. Email proves mailbox control, not legal identity. Only listed fields are returned; invitation secrets and bearer links are never returned.

Input Schema

Name	Required	Description
`id`	No
`email`	No
`limit`	No
`action`	Yes
`cursor`	No
`policy`	No
`approval`	No
`resource_id`	Yes	The resource public key, CRID, or legacy r_ ID to manage access.
`expected_version`	No	Current listed version for configure, resend, revoke_invitation, deny or revoke_grant. Omit on invites and listings; approve uses approval.expected_version.

Output Schema

Name	Required	Description	Default
`grant`	No
`action`	Yes
`grants`	No
`resource`	No
`invitation`	No
`invitations`	No
`next_cursor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.6Oct 27, 2026

addedInput schema / properties / expected_version / description

Added value: +"Current listed version for configure, resend, revoke_invitation, deny or revoke_grant. Omit on invites and listings; approve uses approval.expected_version."

Changed2 schema fields changedv0.2.3Oct 22, 2026
- changedOutput schema / properties / grant / properties / credential_kind / enum
```
Previous value: -[
-  "passkey",
-  "device"
-]New value: +[
+  "passkey",
+  "device",
+  "email"
+]
```
- changedOutput schema / properties / grants / items / properties / credential_kind / enum
```
Previous value: -[
-  "passkey",
-  "device"
-]New value: +[
+  "passkey",
+  "device",
+  "email"
+]
```
Addedv0.2.2Oct 14, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The annotations already flag destructive and non-idempotent behavior, and the description adds important operational context beyond them: accepted delivery does not prove enrollment, invitation secrets and bearer links are never returned, removal is complete only after session_cleanup, and denied listing should be reported as unconfirmed. These are exactly the behavioral caveats an agent needs.

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 description is dense and front-loads some invite-specific rules before laying out the broader action set, which makes it harder to scan. Most sentences carry useful operational information, but the telegraphic style and run-on sequencing reduce clarity and conciseness.

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?

For a complex, destructive, multi-action tool with nested parameters and low schema description coverage, the description covers many critical safety and usage constraints. It is not fully complete because it does not explain all parameters (e.g., limit, cursor, policy modes) or permission requirements, but it is sufficient for careful invocation.

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 low at 22%, but the description compensates substantially by explaining action-specific fields: invite uses only action/resource_id/email, approve places expected_version inside approval, zero is allowed only for id new, and existing requests use the listed decision id and version without credential fields. It still leaves gaps around limit/cursor and several policy fields, so it is not fully complete.

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 identifies the resource as publisher access control for a private CRID and enumerates the supported actions (configure, invite, list, approve/deny, revoke). It is clear what the tool does, but it does not directly distinguish itself from siblings such as publish_crid or share_by_crid.

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 extensive action-specific guidance: invite should use only action/resource_id/email, omit expected_version/approval/policy; listing should page through results; after an uncertain invite, list before retrying; and do not resend when listing is denied. The guidance is strong but somewhat fragmented and does not explicitly compare against sibling tools.

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

Deploy Server