Skip to main content
Glama
aeoess

agent-passport-system-mcp

by aeoess
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

aps_verify_attribution_consent

Verify an attribution receipt end-to-end: checks id, citer and consent signatures, and expiry, while binding each named party to its declared key. Returns validity status and reason if invalid.

Instructions

Representation boundary: verify an AttributionReceipt end-to-end (id, citer signature, consent signature, expiry) and bind each named party to the key beside it. What a valid result establishes: the receipt is intact, unexpired, and signed by the keys its party DIDs commit to. What it does not establish: that either party is authorized for your relying-party decision, or who they are outside the protocol. A party named by an identifier that does not self-certify is refused as unresolved rather than assumed. Returns {valid, reason?}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nowNoOptional HybridTimestamp to pin the evaluation moment
receiptYesAttributionReceipt JSON

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 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
    • addedInput schema / required
      Added value: +[
+  "receipt"
+]
  2. Addedv2.8.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and succeeds: it discloses the exact checks, the meaning of a valid result, the non-guarantees about authorization and identity, the refusal behavior for identifiers that do not self-certify, and the return shape {valid, reason?}. This goes well beyond the tool name and schema.

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?

The description is tightly structured: a one-line boundary statement, followed by clearly labeled valid-result semantics, non-guarantees, refusal semantics, and return shape. No sentence is redundant, and the most important scope information is front-loaded.

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 verification tool with two parameters, full schema coverage, and no output schema, the description supplies the missing return contract and behavioral caveats. An agent can understand what to pass, what success means, what it must not infer, and what response to expect.

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 description coverage is 100%, so the baseline is 3. The description adds context about what the receipt verification establishes, but it does not add parameter-specific meaning beyond the schema's descriptions for receipt and now.

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?

The description states the specific verb 'verify' with the resource 'an AttributionReceipt end-to-end', enumerating the checked elements (id, citer signature, consent signature, expiry) and the party-to-key binding. It also clarifies the scope by explicitly saying what a valid result does and does not establish, distinguishing this end-to-end verification from narrower verification tools among the siblings.

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?

The description conveys a clear intended use: verify a full attribution receipt and interpret its meaning. It lacks explicit naming of sibling alternatives such as aps_verify_attribution_primitive or explicit when-not-to-use conditions, but the 'end-to-end' framing and the 'does not establish' boundary give strong contextual guidance for selection.

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