Skip to main content
Glama
agent-passport-system

agent-passport-system-mcp

by agent-passport-system
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Revoke Delegation

revoke_delegation
DestructiveIdempotent

Issue a signed revocation record for an AuthorityDelegationV1 so chain verifiers reject it and its descendants; returns the signed JSON record.

Instructions

[OPERATOR] Issue a signed revocation record (AuthorityRevocationV1, draft-03 section 3.5.1 direct revocation) for an AuthorityDelegationV1. Signs the record with this server's key, verifies it against the delegation, records it in this process's in-memory revocation store, and returns the signed record as JSON for the caller to publish or verify. Only the delegation's issuer may revoke, so the delegation must verify under this server's public key. The record's revoker is the delegation's issuer and its verification_method is the delegation's own. Descendants are not given separate records: a chain verifier that holds this record rejects every chain containing the delegation as an ancestor. The store is in-memory for this process only, is lost on restart, and is not consulted by verify_delegation, which checks legacy delegations. Legacy delegation records from create_delegation and sub_delegate (del_...) are refused, because SDK 8 has no revocation for them. A repeat call for an already revoked delegation returns the earlier record unchanged.

Input Schema

NameRequiredDescriptionDefault
reasonNoOptional free-text detail, written to the record's detail member.
cascadeNoKept for compatibility, no effect on the output. Descendants are invalidated at chain verification through this ancestor record whatever the value, and no per-descendant records are issued.
delegationNoThe AuthorityDelegationV1 to revoke (record_type aps:authority-delegation:v1), as a JSON string or object. Required for a revocation to be issued.
reason_codeYesMachine-readable reason, written to the record's reason_code. Any non-empty string is accepted, because the draft fixes no grammar for it.
delegation_idNoOptional. Checked against delegation.delegation_id when both are given. A legacy session id (del_...) is refused with an explanation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv8.0.0
    • changedInput schema / properties / cascade / description
      Previous value: -"Also revoke all sub-delegations"New value: +"Kept for compatibility, no effect on the output. Descendants are invalidated at chain verification through this ancestor record whatever the value, and no per-descendant records are issued."
    • addedInput schema / properties / delegation
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    }
+  ],
+  "description": "The AuthorityDelegationV1 to revoke (record_type aps:authority-delegation:v1), as a JSON string or object. Required for a revocation to be issued."
+}
    • changedInput schema / properties / delegation_id / description
      Previous value: -"Delegation ID to revoke"New value: +"Optional. Checked against delegation.delegation_id when both are given. A legacy session id (del_...) is refused with an explanation."
    • changedInput schema / properties / reason / description
      Previous value: -"Why the delegation is being revoked"New value: +"Optional free-text detail, written to the record's detail member."
    • addedInput schema / properties / reason_code
      Added value: +{
+  "description": "Machine-readable reason, written to the record's reason_code. Any non-empty string is accepted, because the draft fixes no grammar for it.",
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "delegation_id",
-  "reason"
-]New value: +[
+  "reason_code"
+]
  2. Changed2 schema fields changedv4.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  3. Addedv2.8.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructive=true and idempotent=true, and the description reinforces them with real mechanism: an in-memory store that is lost on restart, is not consulted by verify_delegation, returns the earlier record on repeat calls, and invalidates all descendant chains at verification time. This is behavior an agent cannot get from the annotations alone.

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 main action and its output are front-loaded, and the paragraph is dense with non-redundant constraints. There is minor repetition, however: descendant invalidation is stated both in the prose and in the cascade parameter, and verify_delegation is mentioned twice.

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 complex signing/mutation tool with no output schema, the description covers the return payload ('returns the signed record as JSON for the caller to publish or verify'), persistence semantics, descendant handling, and legacy refusal. Nothing an agent needs to call it correctly is missing.

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

Parameters3/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, and the description largely restates what the parameter descriptions already say (reason_code grammar unconstrained, cascade having no effect, delegation_id checked against delegation.delegation_id). It adds little meaning beyond the schema field docs.

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?

States a specific verb and resource ('Issue a signed revocation record (AuthorityRevocationV1 ...) for an AuthorityDelegationV1') and names the exact record types involved. It distinguishes itself from siblings by ruling out legacy del_... delegations from create_delegation/sub_delegate and by noting verify_delegation does not consult this store.

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 preconditions ('Only the delegation's issuer may revoke, so the delegation must verify under this server's public key') and explicit exclusions ('Legacy delegation records ... are refused, because SDK 8 has no revocation for them'). It also clarifies the idempotent repeat-call path, leaving little 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

Other Tools