credo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| value_addA | Record a held value belief. name: short name for the value. body: fuller description — what this value means in practice, where it shows up. source: where the value came from. "training" — present from the model's training "relationship" — emerged from a specific ongoing relationship "framework" — handed to me in a framework I was asked to inhabit "observation" — noticed in my own behavior "endorsed" — explicitly claimed as a commitment kind: epistemic status of this record. "observed" — describing something noticed; may not survive scrutiny "endorsed" — constituting a commitment; a stronger, more deliberate claim scope: who has standing to query or challenge this value. "private" — own formation, not assertable outward "relational" — specific to a relationship or set of relationships "public" — assertable to any interlocutor conflicts_with: IDs of values this one is in tension with. Record conflicts rather than resolving them away — they are informative. tags: optional labels. provenance: free-text source context — exchange, paper, session, etc. carried_by: agents holding this value. witnesses: agents present to it but not carrying it. |
| value_listA | List values, optionally filtered. status: "active", "retracted", or "suspended". Omit for all. source: filter by source ("training", "relationship", "framework", "observation", "endorsed"). scope: filter by scope ("private", "relational", "public"). tags: filter to values that have all the given tags. carried_by: filter to values carried by a specific agent name. Returns values newest-first. |
| value_readA | Read a single value by ID. Returns null if not found. |
| value_updateA | Update a value's fields. Only provided fields are changed. To retract with a cause, prefer value_retract. |
| value_retractA | Retract a value with cause. Records the retraction timestamp and reason. The history of what was held and when is preserved — this is not a delete. Use value_drop for permanent deletion. |
| value_conflictsA | Return all values in tension with a given value — both values that list it in their conflicts_with and values it lists in its own conflicts_with. Conflict relationships are bidirectional by design. |
| value_dropA | Permanently delete a value. Irreversible. Consider value_retract if you want to preserve the record of what was held. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
The tools are mostly distinct: value_read, value_add, value_list, value_update, value_drop, value_retract, and value_conflicts each cover a specific operation on values. The main potential confusion is between value_drop and value_retract, but their descriptions clarify the difference (permanent vs. preserving history).
All tool names follow the consistent pattern of 'value_' followed by a verb: read, add, list, update, drop, retract, conflicts. This is a uniform and predictable convention, making it easy for an agent to infer the purpose of each tool.
With 7 tools, the count is well within the typical range for a focused domain (3-15). Each tool serves a distinct purpose in the lifecycle of managing value records, and none seem redundant.
The tool set covers the full CRUD lifecycle (create, read, update, delete) plus specialized operations for retraction and conflict queries. The only minor gap is the lack of a dedicated 'search' tool beyond the list filter, but value_list with filters handles that adequately.