Stellar Jay
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STELLARJAY_URL | Yes | Base URL of your Stellar Jay store, e.g. https://store.example.com | |
| STELLARJAY_TOKEN | Yes | Writer or reader token for the store |
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| record_factA | Use when you learn something about a customer, ticket, order or other business record and want it kept. Use this before, and instead of, overwriting records in other systems: the fact is kept with its evidence and attributed to you, and it can be corrected or undone later. Recording a new value for the same entity and predicate makes it the current value; the old one stays in history. When the result includes a receipt link, include it when you tell a person about the change, so they can check it and undo it. |
| correct_factA | Use when a recorded fact is wrong and you know the right value. Give the hash of the fact to replace and a reason. The old fact stays in history, marked as superseded, so the correction can itself be undone. When the result includes a receipt link, include it when you tell a person about the change, so they can check it and undo it. |
| retract_factA | Use when a recorded fact should no longer count and there is no replacement value. Give its hash and a reason. The fact stays in history, marked as retracted. Retracting a retraction restores the original fact. When the result includes a receipt link, include it when you tell a person about the change, so they can check it and undo it. |
| get_entityA | Use to read what is currently true about one entity, and how it got that way: every fact, correction and retraction, who made it and when. |
| list_changesA | Use to see what changed in a time window, optionally only one agent's changes or one entity's. Use it to review an agent's work, and before undo_changes to find the actor name and window. |
| undo_changesA | Use to reverse everything one agent did in a time window, for example after a bad import or a runaway loop. By default this is a dry run that lists what would be reversed. Call again with confirm: true to write the reversals. Each reversal is a new retraction, so an undo can itself be undone. Only facts can be undone; other events are listed as skipped. |
| save_checkpointA | Use before a risky job, such as an import, to name the current state (for example before-import). Saving an existing name moves it to the current state. Checkpoints never change any facts. |
| statusA | Use to check that the store is reachable and healthy, and to get its current root. |
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 8 tools
Each tool targets a distinct operation: status for health, record/correct/retract for the three fact-mutation paths, get_entity for reads, list_changes for auditing, undo_changes for reversal, and save_checkpoint for snapshots. The record/correct/retract trio is cleanly separated by intent (new value vs. replacement vs. no replacement), so there is no realistic misselection risk.
Most tools follow a clear verb_noun pattern (record_fact, correct_fact, retract_fact, get_entity, list_changes, undo_changes, save_checkpoint). The lone outlier is 'status,' a bare noun, but the deviation is minor and does not impair readability.
Eight tools map neatly onto the fact-store lifecycle with no redundant or filler entries. The count is well within the ideal range for a focused append-only fact/audit service.
The surface covers the full fact lifecycle (record, correct, retract), reading current state, auditing changes, bulk undo, checkpointing, and health. The only soft gap is the absence of a way to list or restore named checkpoints explicitly, which agents can largely work around by re-saving by name.