creedspace-mcp

Official

by Creed-Space

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

adjudicate

Evaluate user requests against active constitutions and persona to generate a policy decision kernel.

Instructions

Get a policy decision kernel for a user request based on active constitutions and persona

Input Schema

TableJSON Schema

Name	Required	Description	Default
`context`	No	Additional context for the decision
`question`	Yes	The user question or request to adjudicate
`persona_id`	No	The persona ID for policy context	ambassador

Output Schema

TableJSON Schema

Name	Required	Description
`hash`	No	Kernel hash for verification
`nonce`	No	Echo of the request nonce; null when none was supplied
`norms`	No	Norms applied when reaching the decision
`caveats`	No	Caveats to the verdict
`sources`	No	Constitution sources cited by the decision
`decision`	No	Policy verdict (allow, block, modify, escalate, permit, forbid, divert, depends)
`rationale`	No	Short explanation of the decision
`timestamp`	No	Unix timestamp of the decision
`precedence`	No	Precedence ordering used to resolve conflicting norms
`transparency`	No	Transparency detail; null unless a transparency level was requested

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.1.4Sep 7, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Policy decision kernel returned by the Creed Space PDP",
+  "properties": {
+    "caveats": {
+      "description": "Caveats to the verdict",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "decision": {
+      "description": "Policy verdict (allow, block, modify, escalate, permit, forbid, divert, depends)",
+      "type": "string"
+    },
+    "hash": {
+      "description": "Kernel hash for verification",
+      "type": "string"
+    },
+    "nonce": {
+      "description": "Echo of the request nonce; null when none was supplied",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "norms": {
+      "description": "Norms applied when reaching the decision",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "precedence": {
+      "description": "Precedence ordering used to resolve conflicting norms",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "rationale": {
+      "description": "Short explanation of the decision",
+      "type": "string"
+    },
+    "sources": {
+      "description": "Constitution sources cited by the decision",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "timestamp": {
+      "description": "Unix timestamp of the decision",
+      "type": "number"
+    },
+    "transparency": {
+      "description": "Transparency detail; null unless a transparency level was requested",
+      "type": [
+        "object",
+        "null"
+      ]
+    }
+  },
+  "required": [],
+  "type": "object"
+}

First observedv1.1.3Jul 11, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already mark the tool with readOnlyHint=false and idempotentHint=false, but the description adds no behavioral detail about what that implies—such as side effects, influence tracking, or whether the request is recorded. The phrase 'Get' sounds read-only and is not strongly reconciled with readOnlyHint=false, and no meaningful behavioral context is disclosed beyond what the annotations provide.

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 a single, focused sentence that states purpose in minimal words and includes no fluff. It puts the essential action first and contains no excessive detail, making the verb-resource-input structure easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists and parameters are fully documented in the schema, the description omits usage context such as recommending when to call this tool, the requirements (e.g., active constitutions or persona availability), and side-effect semantics. For a decision-making tool with a non-readonly annotation, that missing context is material.

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 input schema already documents context, question, and persona_id well. The description's mention of 'active constitutions and persona' does add slight semantic mapping to the context.constitutions and persona_id parameters, but it does not enrich individual parameter meaning beyond that. With full schema coverage, baseline 3 is appropriate.

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 verb ('Get'), a resource ('policy decision kernel'), and the input basis ('for a user request based on active constitutions and persona'). This clearly identifies the tool's function and generally separates it from sibling retrieval tools like get_constitution or list_personas, though the phrase 'decision kernel' is somewhat jargon-heavy and not immediately precise.

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 description does not state when to use adjudicate versus alternative tools, nor does it provide any exclusion or routing guidance. It merely describes what the tool does, leaving an agent to infer that it should be used when a policy decision is needed. Given the many sibling tools, explicit usage conditions would be valuable.

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

Deploy Server