Skip to main content
Glama
agent-passport-system

agent-passport-system-mcp

by agent-passport-system
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Verify Charter

verify_charter
Read-onlyIdempotent

Verifies a charter's integrity, signatures, quorum, and citation consent, confirming it is intact and signed by named keys, and that declared citations have consent receipts.

Instructions

Verify a charter's integrity: content hash, signatures, quorum, dissolution, office consistency, incompatibility, and, when the charter declares citations, the AttributionConsent gate over the receipts you supply. What a valid result establishes: the charter is intact and signed by the keys it names, and any citation it declares is backed by a receipt the cited principal consented to. What it does not establish: that those signers hold the authority your decision needs. A charter declaring citations cannot be valid without attribution_receipts, and fails closed with 'citations present but no receipts supplied'.

Input Schema

NameRequiredDescriptionDefault
charter_idYesCharter ID to verify
attribution_receiptsNoSigned AttributionReceipts backing the charter's citations. Required for a charter that declares any; each receipt's parties must be named by self-certifying DIDs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv6.0.0
    • addedInput schema / properties / attribution_receipts
      Added value: +{
+  "description": "Signed AttributionReceipts backing the charter's citations. Required for a charter that declares any; each receipt's parties must be named by self-certifying DIDs.",
+  "items": {},
+  "type": "array"
+}
  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.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real value beyond that: it defines what a valid result does and does not establish (a deliberate trust-boundary caveat) and discloses fail-closed behavior with the exact error string, which an agent needs to interpret an unsuccessful call.

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?

Three sentences, each carrying distinct load: what is checked, what validity guarantees, what it does not guarantee, and the fail-closed condition. Front-loaded with the verb and resource. Slightly dense syntax ('and, when the charter declares citations, the ... gate over the receipts you supply'), but nothing is wasted.

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?

No output schema exists, so the description must carry the interpretation burden — and it does, explaining what a valid result means and its limits. The failure mode is named with an exact error string. What is left unstated is the shape of a successful response (per-check breakdown vs single boolean), which an agent still has to discover empirically.

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. The description earns more by explaining the conditional coupling between charter content and attribution_receipts — receipts become required only when the charter declares citations — plus the constraint that receipt parties must be named by self-certifying DIDs. That clarifies *why* the optional parameter becomes mandatory, which the schema alone does not.

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 (verify) and resource (charter) and then enumerates exactly what integrity dimensions are checked: content hash, signatures, quorum, dissolution, office consistency, incompatibility, and the AttributionConsent gate. This is clearly distinguishable from sibling tools like sign_charter, create_charter, and verify_amendment without opening any schema.

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?

Gives an explicit conditional: when the charter declares citations, the AttributionConsent gate applies over the receipts you supply, and receipts are mandatory in that case ('citations present but no receipts supplied'). It also scopes the tool's conclusion ('does not establish authority'). It stops short of naming siblings such as verify_amendment or aps_verify_attribution_consent as alternatives for adjacent questions, so 4 rather than 5.

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