agent-passport-system-mcp

Register Data Source

register_data_source

Register a data source with allowed purposes, access limits, and compensation terms, then receive a signed SourceReceipt for agent access.

Instructions

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": {
      "contentDescriptor": "<contentDescriptor>",
      "contentCommitment": "<contentCommitment>",
      "contentType": "<contentType>",
      "allowedPurposes": "<allowedPurposes>"
    },
    "name": "register_data_source"
  }
}

Input Schema

Name	Required	Description	Default
`contentType`	Yes	Type of data
`maxAccessCount`	No	Max total accesses allowed
`allowedPurposes`	Yes	Allowed purposes: read, analyze, summarize, generate, recommend, train, embed, redistribute, commercial
`compensationType`	No		none
`derivativePolicy`	No		attribution_required
`contentCommitment`	Yes	SHA-256 hash of the data content
`contentDescriptor`	Yes	Human-readable description of the data
`compensationAmount`	No	Amount per access (for per_access type)
`requireAttribution`	No
`compensationCurrency`	No		usd

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv4.0.0Aug 1, 2026

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
```

Addedv2.8.0May 1, 2026

TDQS

B3/5.0

Behavior3/5

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

Annotations already state readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false, covering the safety and mutability profile. The description adds one genuinely useful fact beyond the annotations: the call returns a signed SourceReceipt. It does not disclose auth requirements, what happens on duplicate registration, or the significance of the non-idempotent hint.

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?

Two short sentences, purpose front-loaded followed by return-value fact. No waste, though it is arguably under-specified rather than optimally concise.

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?

For a 10-parameter governance tool with no output schema, the description is thin: it names the return artifact but explains none of the terms semantics, required hashes, or access-count limits. The mention of the SourceReceipt compensates partly for the missing output schema, but overall coverage of a complex registration contract is only minimum viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 60%, so the schema does not fully carry the parameter burden. The description mentions no parameters at all and adds zero semantics beyond the schema, leaving the enum-bearing terms (compensationType, derivativePolicy, allowedPurposes) and their interaction unexplained.

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?

Names a specific verb (Register) and resource (a data source) plus the key qualifier 'with terms for agent access', so the agent knows this creates an access-controlled data registration. It does not differentiate itself from the many sibling creation tools (create_data_enforcement_gate, create_derivation_receipt, create_artifact_provenance), so a 4 rather than a 5.

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 phrase 'for agent access' hints at context but there is no explicit when-to-use, when-not-to-use, or named alternative. With dozens of sibling creation/registration tools, the agent gets no routing signal from this description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server