Skip to main content
Glama
aeoess

agent-passport-system-mcp

by aeoess
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

aps_check_artifact_citations

Validate a binding artifact's citations against signed receipts: ensure each citation matches content and principal with replay protection, and reject any citation lacking valid consent.

Instructions

Representation boundary: gate a binding artifact's citations. Each citation must resolve to a provided, signed, unexpired receipt whose content + principal match, with per-artifact replay protection, and each receipt must bind its parties to the keys beside them. What a valid result establishes: every citation is backed by a receipt the cited principal consented to. What it does not establish: authority to act on the artifact. Receipts whose parties are named by identifiers that do not self-certify stop passing this gate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
artifactYesCitingArtifact with optional citations[] array
receiptsYesAttributionReceipts backing each citation
binding_contextNoRequire receipts to be scoped to this binding context

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 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 / properties / receipts / items
      Added value: +{}
    • changedInput schema / required
      Previous value: -[
-  "receipts"
-]New value: +[
+  "artifact",
+  "receipts"
+]
  2. Addedv2.8.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and meets it thoroughly. It discloses validation conditions (signed, unexpired receipts, content + principal match, replay protection, key binding), failure behavior ('stop passing this gate'), and the precise meaning of both a positive result and a non-result. This is well beyond what the schema or name alone communicate.

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 dense but every sentence earns its place: purpose, validation criteria, valid-result semantics, non-implications, and a failure condition. The main purpose is front-loaded, and the remaining sentences efficiently add essential detail without redundancy.

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?

Given no output schema and no annotations, this description is remarkably complete for a complex validation tool. It tells the agent what inputs must satisfy, what a passing result establishes, what it does not establish, and what causes failure. The agent can invoke this tool with a clear mental model of its behavior.

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 coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the property descriptions. It explains what makes receipts acceptable, how citations must resolve, and what binding context implies. It does not map these rules to each parameter name directly, but it enriches the agent's understanding of artifact and receipts enough to justify a 4.

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 opens with a specific verb and resource: 'gate a binding artifact's citations.' It immediately distinguishes this from the many aps_verify_* siblings by focusing on artifact citations backed by receipts, and the validation conditions are clearly enumerated.

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 gives clear context for when this gate is appropriate and explicitly states a limitation: 'What it does not establish: authority to act on the artifact.' It does not name alternative sibling tools, but the boundary semantics and the check/gate framing make the intended use reasonably clear.

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