proofrelay.build_registry_entryBuild a public-safe ProofRelay Registry entry draft for an agent, API, MCP server, workflow, or adapter using only hashes and profile markers.
| Name | Required | Description | Default |
|---|---|---|---|
| entry | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / $defsRemoved value: -{
- "RegistryEntryInput": {
- "description": "Public-safe ProofRelay Registry entry draft input.",
- "properties": {
- "conformance_fixture_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional conformance fixture hash.",
- "title": "Conformance Fixture Hash"
- },
- "entry_type": {
- "description": "Registry subject category.",
- "enum": [
- "mcp_server",
- "agent",
- "api",
- "workflow",
- "adapter"
- ],
- "title": "Entry Type",
- "type": "string"
- },
- "evidence_bundle_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional bundle hash.",
- "title": "Evidence Bundle Hash"
- },
- "identity_reference_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional PREP-3 identity reference hash.",
- "title": "Identity Reference Hash"
- },
- "mcp_server_card_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional MCP server-card hash.",
- "title": "Mcp Server Card Hash"
- },
- "name": {
- "description": "Public display name, no secrets.",
- "title": "Name",
- "type": "string"
- },
- "non_secret_refs": {
- "description": "Public-safe listing references.",
- "items": {
- "type": "string"
- },
- "title": "Non Secret Refs",
- "type": "array"
- },
- "openapi_schema_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional OpenAPI schema hash.",
- "title": "Openapi Schema Hash"
- },
- "payment_context_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional payment context hash.",
- "title": "Payment Context Hash"
- },
- "profiles": {
- "description": "PREP profiles supported by the subject.",
- "items": {
- "type": "string"
- },
- "title": "Profiles",
- "type": "array"
- },
- "proof_envelope_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional proof hash.",
- "title": "Proof Envelope Hash"
- },
- "replay_test_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional replay test hash.",
- "title": "Replay Test Hash"
- },
- "status": {
- "default": "draft",
- "description": "Public registry workflow status.",
- "enum": [
- "draft",
- "evidence_submitted",
- "verified_bundle",
- "replay_tested",
- "listed"
- ],
- "title": "Status",
- "type": "string"
- },
- "subject_hash": {
- "description": "SHA-256 hash of registry subject.",
- "title": "Subject Hash",
- "type": "string"
- },
- "verifier_response_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional verifier response hash.",
- "title": "Verifier Response Hash"
- }
- },
- "required": [
- "entry_type",
- "name",
- "subject_hash"
- ],
- "title": "RegistryEntryInput",
- "type": "object"
- }
-}Input schema / properties / entry / $refRemoved value: -"#/$defs/RegistryEntryInput"Input schema / properties / entry / propertiesAdded value: +{
+ "conformance_fixture_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "entry_type": {
+ "enum": [
+ "mcp_server",
+ "agent",
+ "api",
+ "workflow",
+ "adapter"
+ ],
+ "type": "string"
+ },
+ "evidence_bundle_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "identity_reference_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mcp_server_card_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "non_secret_refs": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "openapi_schema_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "payment_context_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "profiles": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "proof_envelope_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "replay_test_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "enum": [
+ "draft",
+ "evidence_submitted",
+ "verified_bundle",
+ "replay_tested",
+ "listed"
+ ],
+ "type": "string"
+ },
+ "subject_hash": {
+ "type": "string"
+ },
+ "verifier_response_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+}Input schema / properties / entry / requiredAdded value: +[
+ "entry_type",
+ "name",
+ "subject_hash"
+]Input schema / properties / entry / typeAdded value: +"object"Input schema / titleRemoved value: -"build_registry_entryArguments"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction. The description says 'Build a registry entry draft,' implying a create/write operation, but readOnlyHint: true is set, which asserts no state modification. No other behavioral side effects are disclosed (e.g., persistence status, hashing process, approval controls).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One long but readable sentence. No padding, clear phrasing, aligned with the tool name and title. Could be slightly smaller by removing the entity list, but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex: a single deeply-nested entry parameter, ~22 optional or conditional fields, no parameter descriptions, and no output schema documentation. The description covers the type of target at a high level but never mentions return formats, behavior on validation failure, ordering constraints, or related chain interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, and the nested 'entry' object with many fields/options is not explained. The description only says it accepts hashes/profile markers, but does not explain the per-field meanings (entry_type, subject_hash, profile markers, status, hash references, etc.).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear action ('build') and object ('registry entry draft'), and enumerates acceptable entity types (agent, API server, MCP server, workflow, adapter). Does not explicitly contrast with sibling tools, but the name 'build_registry_entry' is specific enough to distinguish registry creation from audit/bundle/verification operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an implicit constraint ('using only hashes and profile markers'), but no explicit when-to-use vs alternatives, no exclusions/alternatives, and no prerequisites or postconditions for creating a registry draft.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.