Skip to main content
Glama
Sign In
agent-passport-system-mcp

agent-passport-system-mcp

by agent-passport-system
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Sub-Delegate Authority

sub_delegate

Grant another agent limited authority from your existing delegation, ensuring scope and spend limits stay within parent constraints.

Instructions

Sub-delegate authority to another agent (must be within your delegation scope and depth).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "parent_delegation_id": "<parent_delegation_id>",
      "delegated_to": "<delegated_to>",
      "scope": "<scope>",
      "spend_limit": "<spend_limit>"
    },
    "name": "sub_delegate"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeYesScopes to grant (must be subset of parent)
spend_limitYesMaximum spend (must be <= parent)
delegated_toYesPublic key of the agent receiving sub-delegation
parent_delegation_idYesYour delegation ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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
  2. Addedv2.8.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare the safety profile (write, non-idempotent, not open-world, not destructive). The description adds the meaningful invariant that sub-delegation is bounded by the caller's own scope and depth. It omits other behavior an agent needs: that non-idempotency means repeated calls create separate delegations, and what happens when limits are exceeded.

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?

A single front-loaded sentence with the action first and the constraint second; no filler. It is lean to the point of being sparse, but nothing is wasted.

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

Completeness3/5

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

With full schema coverage and annotations present, and no output schema, the description covers the core action and its bound. For an authority-granting operation in a governance-heavy toolset, it should still say whether the grant is revocable, how the resulting delegation is identified, or how it relates to revoke_delegation.

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 all four parameters are documented in the schema with their subset/bounds constraints. The description's 'within your delegation scope and depth' largely restates the schema's own 'must be subset of parent' / 'must be <= parent' notes rather than adding new semantics. Baseline 3 applies.

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?

Specific verb+resource: granting (sub-delegating) authority to another agent. The 'sub-' prefix and 'within your delegation scope' implies a derived delegation distinct from root-level siblings like create_delegation or create_v2_delegation, but it never names or contrasts with those siblings explicitly.

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 parenthetical prerequisite ('must be within your delegation scope and depth') tells the agent the condition under which the call is valid, which implies when to use it. However, there is no explicit when-not guidance, no mention of revoke_delegation or create_delegation as alternatives, and no statement about what happens on failure.

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