Skip to main content
Glama
agent-passport-system

agent-passport-system-mcp

by agent-passport-system
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Compute Action Reference

compute_action_ref
Read-onlyIdempotent

Compute a deterministic SHA-256 request identity from agent ID, action type, required scope, and normalized timestamp, so matching receipts describe the same request.

Instructions

Compute content-addressed request identity (SHA-256 of agentId + actionType + scope + normalized timestamp). Two receipts with the same action_ref describe the same request.

Input Schema

NameRequiredDescriptionDefault
agent_idYes
timestampNoRFC 3339 timestamp carrying an explicit offset or Z; defaults to now. A zone-less value is refused, because it names no instant and would produce a different action_ref on every machine.
action_typeYes
scope_requiredYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv6.0.0
    • changedInput schema / properties / timestamp / description
      Previous value: -"ISO 8601 timestamp; defaults to now"New value: +"RFC 3339 timestamp carrying an explicit offset or Z; defaults to now. A zone-less value is refused, because it names no instant and would produce a different action_ref on every machine."
  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

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, and closed-world behavior, so the bar is lower. The description earns credit by disclosing the deterministic hash composition and the equality semantics of the output, which annotations cannot express. It omits details like whether scope_required ordering affects the hash, but overall it adds real behavioral context.

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?

Two sentences, no filler. The identity of the operation and its exact formula come first, followed by the interpretive meaning of the output. Every clause is load-bearing.

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?

There is no output schema, so the description must characterize the return value; saying it is a SHA-256 action_ref plus the equality property largely does that. Minor gap: nothing says whether array ordering in scope_required is canonicalized, which matters for a content-addressed hash.

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 only 25% (only timestamp is documented), so the description must compensate. The formula 'agentId + actionType + scope + normalized timestamp' effectively assigns a role to all four parameters, and the schema's timestamp note explains the offset/normalization requirement, which is the trickiest input.

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?

The description names a specific operation (compute a content-addressed request identity) and specifies the exact hash construction: SHA-256 over agentId, actionType, scope, and normalized timestamp. That is far more precise than a restated title. It does not, however, distinguish this from the sibling aps_compute_attribution_action_ref, which an agent could easily confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence explains the semantics of the result (two receipts with the same action_ref describe the same request) but gives no instruction on when to call this, when not to, or how it relates to the similarly named action_ref sibling. An agent must infer the use case entirely.

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