A
licenseNot graded
qualityA
maintenanceThe decision system for agentic engineering: keeps your project's decisions, rationale, and rejected paths in plain files and surfaces them to AI coding agents before they plan or change code.
10
Apache 2.0
rostra
Rostra is an MCP server for durable, evidence-backed deliberation and decision making using multiple LLM models and configurable protocols.
Run deliberations: start, list, get, tail, cancel, and resume durable jobs (
start_deliberation,list_deliberations,get_deliberation,tail_deliberation,cancel_deliberation,resume_deliberation).Choose deliberation protocols:
quick,conference,red_team,delphi,premortem, andevidence_tribunal, each with defined model stages and ballot contracts.Use explicit or adaptive committees: supply participants manually or let Rostra select models based on calibrated metrics, cost, latency, and provider-family constraints.
Review decision packets: access structured results containing claims, evidence provenance, predictions, ballots, minority reports, assumptions, agreements, and experiment proposals.
Manage decisions over time: query decisions, list stale decisions, record observed outcomes, and review Git changes against workspace decisions (
query_decisions,list_stale_decisions,record_decision_outcome,review_decision_change).Inspect and tune models: list enabled models, set session-level adapter model defaults, and read quality metrics such as success rates, costs, latency, and calibration.
Access deliberations as resources: subscribe to job URIs, receive progress notifications, and tail event streams with cursors.
Operate over stdio or HTTP: serve the same MCP tool surface via stdio or Streamable HTTP, with loopback protection and shared process-wide state for HTTP clients.
Run decision CI from the CLI: review a Git range and get text, JSON, or SARIF findings with exit codes for failing on warnings or errors.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@rostraRun a premortem protocol on the Q3 migration plan"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The famous Rostra in the Roman Forum, decorated with the bronze beaks of captured enemy ships, where public speakers would stand
Rostra is an MCP server for durable, evidence-backed deliberation and decision making harnessing the power of multiple LLM models/harnesses.
Deliberation protocols
Rostra includes six protocol presets. Each preset defines a sequence of model stages and a structured result contract.
Stage names guide the models, but Rostra does not inject full facilitator scripts or fixed attacker and defender personas.
Protocol | Stages | Use it for | Model rounds |
| Independent analysis → ballot | Low-cost decisions that need independent views and a final vote | 2 |
| Independent analysis → critique → revision → ballot | General decisions that benefit from peer critique and revision | 4 |
| Proposal → adversarial attack → defense → ballot | Stress-testing proposals against counterarguments and failure modes | 4 |
| Independent analysis → anonymous aggregate → revision → ballot | Reducing identity and authority effects before revision | 3, plus local aggregation |
| Premortem → revision → ballot | Surfacing execution risks before a final decision | 3 |
| Proposal → evidence → cross-examination → adjudication → ballot | Repository decisions that require inspectable evidence | 5, plus evidence continuations |
One model round runs all committee participants concurrently. Later preset stages receive prior responses without participant identities.
The delphi aggregate is deterministic and local. It counts exact recommendation strings without a model or semantic clustering.
The evidence_tribunal protocol permits bounded file, search, tree, Git status, and Git diff operations. Rostra validates cited evidence IDs.
The premortem preset supplies a stage label and an analysis contract. It does not run a separate failure simulation.
Choose one committee mode for any protocol:
explicit: Supply all participants.adaptive: Supply committee size and routing limits. Rostra selects configured models from calibrated metrics.
Every model response has a stage-specific schema. Rostra permits one structural repair attempt when a response does not match that schema.
The final ballot requires a two-thirds quorum. Rostra reports ballot consensus separately from semantic convergence and preserves minority rationales.
Custom protocols can change stage order, visibility, minimum completions, evidence permissions, and stopping policies. They can also add experiment-proposal stages.
Related MCP server: Coordination Memory MCP
Requirements
Node.js 24 or newer
One configured model adapter
CLI adapters also require their matching executable. HTTP adapters require access to their configured endpoint.
Git and pnpm 10.11.0 are only required for a source install.
Install
Install the exact beta version, then create the user configuration and data directory:
npm install --global @engineereddev/rostra@0.1.0-beta.2
rostra initInstall from source
git clone https://github.com/EngineeredDev/rostra.git
cd rostra
pnpm install --frozen-lockfile
pnpm build
node dist/cli/main.js initThe init command creates the user configuration and data directory. It also downloads and verifies the pinned MiniLM model when required.
Edit ~/.config/rostra/config.yaml. Enable only the adapters and models that you use.
The same command is safe to run after an upgrade. It never replaces an existing configuration.
Rostra reads configuration from the first available path:
ROSTRA_CONFIG$XDG_CONFIG_HOME/rostra/config.yaml~/.config/rostra/config.yamlThe packaged
config.example.yaml
Rostra writes rostra.sqlite, transcripts, and model files to the data directory. It selects this directory in the following order:
ROSTRA_DATA_HOME$XDG_DATA_HOME/rostra~/.local/share/rostra
Configuration
Use config.example.yaml as a starter configuration.
Supported CLI adapters are claude, codex, droid, gemini, llamacpp, and omp. Supported HTTP adapters are ollama, lmstudio, openrouter, nebius, and openai.
The model registry controls the model IDs, reasoning efforts, capabilities, provider families, costs, and latency estimates available for routing.
The default local_minilm similarity provider uses a pinned MiniLM model. The openai_compatible provider supports a remote embedding endpoint instead.
Configure an MCP client
Pin the package version so a client restart cannot install a different release:
{
"mcpServers": {
"rostra": {
"command": "npx",
"args": ["--yes", "@engineereddev/rostra@0.1.0-beta.2"]
}
}
}The server uses stdio transport by default. It writes protocol messages only to standard output.
HTTP transport
rostra serve --http serves the same tool surface over Streamable HTTP at /mcp:
node dist/cli/main.js serve --http --port 8787Point a client at http://127.0.0.1:8787/mcp. One HTTP process serves every client, so the
embedding model is loaded once instead of once per stdio client.
The endpoint has no authentication. It binds 127.0.0.1 and rejects any request whose Host
or Origin header is not loopback. Do not expose it to a network you do not control. Configure
the bind address, port, subscription cap, and keep-alive interval under http: in config.yaml;
--host and --port override them.
--host 0.0.0.0 prints a warning and is only meant for containers, where the loopback bind is
unreachable through -p. Publish it on the host's loopback address:
docker run -p 127.0.0.1:8787:8787 rostra serve --http --host 0.0.0.0rostra serve --stdio is the explicit form of the default; bare rostra still means
stdio.
Both transports keep the build identity captured at startup. Rebuilding or editing the
configuration underneath a running server makes the next dispatch fail with
stale_server_build; restart the server.
Manage deliberations
Submit a durable job with start_deliberation. Only valid ballots from the final completed ballot stage affect consensus.
Use these tools to manage jobs:
start_deliberationlist_deliberationsget_deliberationtail_deliberationcancel_deliberationresume_deliberation
A recovered job can enter recovery_required after an uncertain external attempt. Call resume_deliberation with retry or cancel to resolve it.
Deliberations as resources
Every job is also readable as a resource. Clients do not have to poll a tool:
rostra://deliberations/{job_id}returns whatget_deliberationreturns.rostra://deliberations/{job_id}/eventsreturns the first 500 events and anext_seqcursor.
Use tail_deliberation when you need a custom cursor, limit, or blocking wait.
Both are URI templates, so they appear under resources/templates/list rather than
resources/list. The server advertises resources.subscribe, and a client on the 2026-07-28
protocol can subscribe to a job's URIs and receive notifications/resources/updated as the job
moves. Job transitions happen in detached worker processes, so the server discovers them by
polling the database every jobs.poll_interval_ms; a subscriber sees a change one interval late.
Blocking calls also report progress. When get_deliberation(wait_for_terminal) or
tail_deliberation(wait_for_change) is called with a progress token, each newly recorded job
event is sent as notifications/progress, keyed by the event sequence number.
Decisions and outcomes
Each completed job publishes an immutable decision packet. The packet includes claims, evidence provenance, predictions, ballots, minority reports, and experiment proposals.
Experiment proposals are inert records. Rostra does not run their commands.
Decision data is scoped to the canonical Git workspace. Use these MCP tools:
query_decisionslist_stale_decisionsrecord_decision_outcomereview_decision_change
record_decision_outcome appends an observed outcome. It never changes an earlier outcome. Resolved prediction labels update model calibration metrics.
Decision CI
Review a Git range from the command line:
node dist/cli/main.js decision review \
--working-directory /path/to/repository \
--base origin/main \
--head HEAD \
--format json \
--fail-on warning--format accepts text, json, or sarif. --fail-on accepts error, warning, or none.
The command returns these exit codes:
0: no finding meets the threshold.1: invalid input or runtime failure.2: at least one finding meets the threshold.
Decision CI reports stale evidence, changed assumptions, conflicting decisions, superseded precedents, and outcome regressions. It does not modify the repository.
Command-line utilities
The CLI also initializes user files and manages jobs and model files:
node dist/cli/main.js init
node dist/cli/main.js jobs list
node dist/cli/main.js jobs cancel <job-id>
node dist/cli/main.js models fetchjobs list returns the 100 most recent jobs as JSON. jobs cancel requests idempotent cancellation for one job.
Model and quality tools
list_modelslists enabled configured models.set_session_modelschanges adapter defaults for the whole server process. Over HTTP one process serves every client, so these overrides are shared rather than per-client.get_quality_metricsreturns attempts, ballots, failures, latency, cost, and prediction calibration.
Adaptive routing uses Laplace-smoothed success rates and Brier calibration. It also enforces provider-family, cost, and latency constraints.
Evidence boundary
Built-in evidence tools confine file and Git access to the canonical workspace. They reject traversal, symlink escapes, and unsupported Git arguments.
CLI model adapters run as unrestricted host processes. Their decision packets use host_unrestricted as the execution isolation value. Set execution.allow_host_tools: true to permit them.
Docker
Build the image:
docker build -t rostra .Run the MCP server with a mounted configuration and data directory:
docker run --rm -i \
-e ROSTRA_CONFIG=/config/config.yaml \
-v "$PWD/config.yaml:/config/config.yaml:ro" \
-v rostra-data:/home/node/.local/share/rostra \
rostraRun the HTTP transport instead, published on the host's loopback address:
docker run --rm -p 127.0.0.1:8787:8787 \
-e ROSTRA_CONFIG=/config/config.yaml \
-v "$PWD/config.yaml:/config/config.yaml:ro" \
-v rostra-data:/home/node/.local/share/rostra \
rostra serve --http --host 0.0.0.0The container must bind 0.0.0.0 to be reachable through -p, which is why the published port
is pinned to 127.0.0.1. The endpoint is unauthenticated.
The image includes Git. It does not include third-party model CLIs.
Development
pnpm build
pnpm typecheck
pnpm lint
pnpm format:check
pnpm test
pnpm generate:schemasGenerated MCP input and output schemas are in docs/generated/tool-schemas.json.
License
MIT
Available Tools
13 toolscancel_deliberationC
Request idempotent job cancellation
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| reason | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does reveal one useful trait, idempotency, and hints at the operation being a 'request' rather than a direct action, but it does not explain what happens to the job, whether cancellation is reversible, or what side effects occur.
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?
The description is a short, front-loaded phrase with no filler words. It is efficient and to the point, though the brevity contributes to the lack of contextual detail in other dimensions.
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?
For a mutation-style tool with no annotations, the description is too thin. It lacks usage conditions, parameter behavior, and post-cancellation semantics. The presence of an output schema helps, but does not compensate for missing operational context.
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 0%, so the description should compensate for undocumented parameters. It does not explicitly map job_id to the job to cancel or explain the optional reason parameter; job_id can be loosely inferred from the word 'job', but reason is entirely 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?
The description uses the specific verb 'cancel' and identifies the target as a 'job', which clearly conveys the operation. It is not a tautology of the tool name, though calling the resource a 'job' rather than 'deliberation' introduces slight ambiguity in this deliberation-focused toolset.
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?
No guidance is given on when to use this tool versus siblings such as resume_deliberation or start_deliberation. There is no mention of preconditions, such as whether the job must currently be running, or whether cancellation is appropriate after completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_deliberationC
Get one job by ID or idempotency key
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | ||
| idempotency_key | No | ||
| include_attempts | No | ||
| wait_for_terminal | No | ||
| wait_timeout_seconds | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It only says 'Get one job', giving no indication that the tool can wait for terminal states via wait_for_terminal and wait_timeout_seconds, or that include_attempts controls whether attempt data is returned. This is a significant transparency gap given the tool's optional behavioral parameters.
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?
The description is a single sentence with no fluff, making it easy to parse and front-loaded with the core action. It is concise to the point of being terse, but conciseness itself is handled well.
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?
Given the tool has five parameters, including behavior-modifying flags like wait_for_terminal, and no annotations to compensate, the description is far too sparse. It omits critical usage context such as blocking behavior, idempotency semantics, and what distinguishes this from tail_deliberation. The output schema fills in return-value structure, but not the operational context an agent needs to select and invoke the tool correctly.
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?
The description adds some meaning by explaining that job_id and idempotency_key are alternative lookup mechanisms. However, with schema description coverage at 0%, the description must also clarify the role of include_attempts, wait_for_terminal, and wait_timeout_seconds, and it does not. The requirement to supply at least one lookup key is only implied, not enforced or explained.
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 clearly states a specific verb ('Get') and resource ('one job'), and it names the two lookup methods (by ID or idempotency key). It distinguishes itself from list_deliberations by emphasizing 'one job', but it does not explicitly contrast with tail_deliberation, which also targets a single deliberation, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you already have a job ID or idempotency key, which gives useful context. However, it does not explicitly state when to prefer this over list_deliberations, tail_deliberation, or other sibling tools, nor does it mention any exclusions such as needing a terminal state or using a different tool for streaming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quality_metricsB
Read durable model quality metrics
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| domain | No | ||
| adapter | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Read', which implies a safe, non-mutating operation, and 'durable' hints at persisted metrics, but it does not clarify filtering behavior, optionality of parameters, or how the metrics relate to models, domains, or adapters. This is sparse for a tool with no annotation safety signals.
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?
The description is a single concise sentence with no redundancy or extra filler. However, the qualifier 'durable' is not explained and may create ambiguity, so it does not fully earn its place.
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?
Even with an output schema present, the description omits important contextual information: what quality metrics are tracked, what domain and adapter mean, whether combinations of parameters are valid, and what 'durable' implies about freshness or persistence. A read tool with three optional parameters and zero schema descriptions needs more context than this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the three parameters, but it does not. Only 'model' is hinted at by 'model quality metrics'; 'domain' and 'adapter' are left entirely unexplained. The parameter names and regex patterns do not provide sufficient semantic meaning for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a specific resource ('durable model quality metrics'), clearly distinguishing this from sibling tools that handle deliberations, decisions, and model sessions. No sibling appears to target quality metrics, so an agent can route to this tool without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this tool when you want model quality metrics. However, there is no explicit when-to-use guidance, no discussion of when not to use it, and no mention of alternatives such as query_decisions or list_models. The guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_deliberationsC
List durable deliberation jobs
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| statuses | No | ||
| created_after | No | ||
| created_before | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not disclose pagination behavior, default limits, status filtering, or what a 'durable deliberation job' entails. Important operational context is missing.
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?
The description is extremely concise and front-loaded, with no filler words. The single sentence earns its place but is so short that it sacrifices useful context. It is efficient, not bloated, though slightly under-specified for the tool's complexity.
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?
Given the tool has five parameters, no annotations, and an output schema that may document return fields, the description is not complete enough for reliable invocation. It fails to clarify pagination semantics, the meaning of statuses, the 'durable' qualifier, or when to choose this instead of a sibling tool.
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 0%, and the description adds no meaning for the five parameters. While names like limit, cursor, statuses, created_after, and created_before are somewhat self-explanatory, the description does not explain how they interact or which combinations are valid, leaving the agent to infer semantics from bare schema constraints.
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 states a clear verb and resource: 'List durable deliberation jobs.' This distinguishes it from sibling tools like get_deliberation and tail_deliberation, which imply fetching a single or streaming job. However, it does not explicitly differentiate itself from other list-style siblings or explain what 'durable' means.
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?
There is no guidance on when to use this tool versus get_deliberation, tail_deliberation, or cancel_deliberation. The description does not mention pagination, status filtering, or time-range filtering, so an agent must infer intent solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsB
List enabled configured models
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| adapter | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the behavioral burden. 'List' implies a read-only operation and 'enabled configured' communicates the scoping, but the description does not explicitly address side effects, authorization, or behavior with no models. For a benign read tool, this is adequate but not rich.
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 four words with no filler, and the core operation is front-loaded. Every word earns its place.
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?
The output schema handles return values and the tool is simple, but the description omits the adapter parameter's purpose and gives no usage guidance. Because schema description coverage is 0%, the definition is incomplete for correct invocation beyond the no-argument case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, adapter, is undocumented in both the schema and the description. The schema provides only a regex pattern, and the description never explains that adapter filters the listing or what semantic values are allowed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('enabled configured models') with clear scope. This distinguishes it from the sibling tools, which operate on deliberations, decisions, or session model assignment rather than the model catalog.
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?
No guidance is given about when to use this tool versus alternatives. It does not mention set_session_models or any other sibling, so an agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_stale_decisionsC
List stale decisions in the current workspace
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| working_directory | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List,' which implies a read-only operation, but it never explains how stale is determined, how cursor and limit affect pagination, or any ordering or filtering behavior. This is a meaningful gap given the absence of annotation support.
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?
The description is a single short sentence with no filler and the main action is front-loaded. It is concise, but it is also sparse enough that the sentence does not carry much informational weight beyond the tool name.
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?
Even though an output schema exists and covers return values, the central concept of 'stale' is unexplained and there is no guidance to distinguish this from query_decisions. With pagination parameters and a required working_directory, a one-sentence description is not enough for complete contextual understanding.
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 0%, so the description needs to compensate for the parameters. It loosely maps 'current workspace' to working_directory but says nothing about limit or cursor semantics. An agent can infer their roles from the schema, but not their interaction or how staleness relates to them.
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 ('List'), a specific resource ('stale decisions'), and a scope ('current workspace'), which is enough to identify the core operation. However, 'stale' is not defined and there is no distinction made from sibling tools like query_decisions, so full purpose clarity is not achieved.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention what staleness means, when to prefer query_decisions, or any exclusions. The only implied context is the current workspace, but that alone is insufficient for an agent to choose this tool confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_decisionsC
Query decisions in the current workspace
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| format | No | summary | |
| threshold | No | ||
| query_text | No | ||
| decision_id | No | ||
| include_stale | No | ||
| continuation_id | No | ||
| working_directory | Yes | ||
| find_contradictions | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavior disclosure. It implies a read-only query, but does not mention pagination behavior, stale-decision handling, contradiction checking, or any other operational traits an agent would need to anticipate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, so it is not bloated. However, for a tool with ten parameters, a single generic sentence provides very little structure or useful orientation.
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?
The output schema covers return values, but the description is far too thin for a tool with ten parameters, no annotations, and multiple related siblings. It leaves out filter semantics, pagination, stale behavior, and when to use this instead of list_stale_decisions, so an agent would likely need to inspect schemas or guess.
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 0%, and the description adds only the notion of 'current workspace,' which maps to working_directory. The other nine parameters are left entirely to schema names and defaults, with no guidance on how filters, cursor, continuation_id, or format interact.
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 clearly identifies a specific action ('Query') and a specific resource ('decisions') within a defined scope ('current workspace'). It does not, however, distinguish this from sibling tools like list_stale_decisions, so it earns 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?
There is no guidance about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or relationships to other decision-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_decision_outcomeC
Append an observed decision outcome
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| status | Yes | ||
| decision_id | Yes | ||
| observed_at | Yes | ||
| measurements | Yes | ||
| working_directory | Yes | ||
| superseding_decision_id | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. 'Append' conveys an additive, non-overwriting write, but it doesn't mention side effects, whether a prior decision must exist, validation behavior, or idempotency. This is thin for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The phrase is compact, front-loaded, and free of fluff. However, it is under-specified as a definition for a 7-parameter tool with nested objects; brevity is achieved by omitting useful context rather than packing it efficiently.
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?
The schema and output schema carry much of the structured detail, so restating return values isn't necessary. Still, the tool sits within a deliberation lifecycle with no mention of when outcome recording happens, whether it depends on a prior decision, or how it relates to review_decision_change. An agent must infer the operative context.
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 0%, and the description doesn't reference any parameter. The schema itself provides rich constraints (required fields, status enum, UUID/date formats), but the description adds no meaning to decision_id, status, observed_at, measurements, or working_directory.
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 action ('Append') and object ('observed decision outcome'), so the tool's core purpose is clear. It doesn't explicitly differentiate from siblings like review_decision_change or query_decisions, but 'append' implies a distinct write operation.
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?
There is no guidance about when to use this tool, what prerequisites exist, or when to prefer a sibling such as review_decision_change or query_decisions. The only context is implied by the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resume_deliberationC
Resolve a recovery-required uncertain attempt
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| uncertain_attempt_policy | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral implications. It only says the tool 'resolves' an uncertain attempt, without explaining what happens to the job, whether retry or cancel changes state, whether the operation is destructive, or what side effects occur. This is minimal and insufficient for understanding the tool's actual behavior.
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?
The description is a single sentence with no filler or redundant wording. It is front-loaded with the primary action, so it earns a good conciseness score even though it lacks detail elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description is far too skeletal to enable correct invocation. It lacks parameter semantics, usage context, behavioral consequences, and any guidance for choosing retry or cancel. The tool is not adequately specified for an AI agent to use safely or correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention job_id or uncertain_attempt_policy at all. It does not clarify how the policy influences the resolution, what job_id refers to, or why both parameters are required. With no structured descriptions and no compensation in the description, parameter semantics are effectively absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resolve') and identifies a resource ('a recovery-required uncertain attempt'), but it is vague about what resolving actually entails and does not clearly connect to the tool name 'resume_deliberation'. It also does not distinguish this from sibling tools like cancel_deliberation or get_deliberation, leaving the agent to infer the exact scope of the operation.
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?
There is no explicit guidance on when to use this tool versus alternatives. The phrase 'recovery-required uncertain attempt' weakly implies a context, but it never states conditions, prerequisites, or contrasts with sibling tools. An agent cannot reliably determine when resume_deliberation is the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_decision_changeC
Review a Git change against workspace decisions
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| fail_on | No | warning | |
| base_ref | Yes | ||
| head_ref | Yes | ||
| working_directory | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Review' weakly implies a read-only operation, but the description does not say whether it modifies anything, what it requires (e.g., committed refs), how it handles failures, or any side effects.
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?
The single sentence is tight, free of filler, and front-loads the core action. It is slightly too terse for the tool's complexity, but as a concise statement of purpose it is effective.
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?
Given four parameters, an output schema, and no annotations, the description leaves out critical context such as fail_on semantics, what the review output represents, and any preconditions. An agent would need to inspect the schema and output schema to safely invoke it correctly.
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 0% and the description only adds the 'Git change' and 'workspace decisions' framing, which hints at base_ref/head_ref and working_directory. It does not clarify the meaning of fail_on or the expected format/order of the refs.
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 uses a specific verb ('Review') and identifies the resource ('a Git change') and comparison target ('workspace decisions'), which is enough to distinguish it from sibling deliberation and decision-query tools. It doesn't explicitly contrast with query_decisions or list_stale_decisions, but the Git-change angle makes the purpose clear.
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?
There is no guidance about when to prefer this tool over alternatives, nor any exclusions or prerequisites. The only usage signal is the implied scenario of having a Git change, but no sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_session_modelsA
Set default models by adapter for this server process. The overrides are process-scoped, so every client connected to the same HTTP endpoint shares them.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| models | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose an important behavioral trait: the overrides are process-scoped and shared by all clients on the same HTTP endpoint. However, it does not mention persistence, whether null values clear overrides, replacement semantics, or side effects beyond sharing.
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 two sentences with no filler. The first sentence states the action and target; the second explains the key scoping consequence. Information is front-loaded and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description is largely complete: it explains what is set, at what scope, and which clients are affected. The main gap is the lack of explicit null-clearing semantics, but the schema already showing null as an allowed value reduces the need for a detailed explanation.
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 0%, so the description must compensate for documenting the models parameter. It partially does by explaining that models are 'by adapter' and are 'default models', which clarifies the object's mapping purpose. It does not explain that null values likely clear a default or what the adapter keys refer to, leaving some semantic burden on the schema.
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 states a specific action ('Set default models') and a specific resource ('by adapter'), and clarifies the scope ('for this server process'). It is clear and unambiguous, but it does not explicitly differentiate itself from sibling tools such as list_models, so it stops short of 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by explaining its process-scoped behavior, but it never explicitly states when to prefer this tool over alternatives or what conditions make it inappropriate. The usage context is inferable but not stated as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_deliberationC
Submit a durable deliberation job
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | ||
| question | Yes | ||
| committee | Yes | ||
| force_new | No | ||
| domain_tags | No | ||
| max_cost_usd | No | ||
| participants | No | ||
| session_models | No | ||
| continuation_id | No | ||
| idempotency_key | No | ||
| deadline_seconds | No | ||
| decision_options | No | ||
| working_directory | Yes | ||
| allow_unknown_cost | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the burden of behavioral disclosure. 'Durable' and 'Submit' hint that this launches a persistent background job, but the description fails to mention that this may incur cost, is asynchronous, creates resources, or should be tracked via get/tail/list tools.
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?
The description is a single sentence with no wasted words and a clear action first. However, it is concise to the point of being underspecified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, nested objects, no annotations, and no schema descriptions, a one-line description is completely inadequate. Even though an output schema exists, the agent still lacks essential context about what a deliberation job is, how its inputs relate, what side effects occur, and how to interact with the resulting job.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 14 parameters with 0% schema description coverage, yet the description adds no meaning for any of them. An agent is left to guess what protocol, committee, participants, max_cost_usd, continuation_id, and decision_options actually represent. The required field names provide only weak hints.
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 clearly identifies the action ('Submit') and the resource ('a durable deliberation job'), which indicates this tool creates/starts a new deliberation. It is reasonably distinguishable from sibling tools like list_deliberations, get_deliberation, and cancel_deliberation, though it does not explicitly call out those distinctions.
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 provides no guidance about when to use start_deliberation versus resume_deliberation, list_deliberations, or cancel_deliberation. It also says nothing about use cases such as initial submission versus continuation, or when idempotency or force_new fields should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tail_deliberationC
Read job events after a sequence cursor
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| job_id | Yes | ||
| after_seq | No | ||
| wait_for_change | No | ||
| wait_timeout_seconds | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only states read-only cursor-based reading. It does not disclose the long-polling/wait behavior implied by wait_for_change and wait_timeout_seconds, event ordering guarantees, or how cursor advancement works. This is a significant transparency gap for a potentially blocking tool.
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?
The description is a single front-loaded sentence with no filler or redundancy. However, it is quite terse for a tool with five parameters and potentially blocking behavior, so it sacrifices completeness for brevity.
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, the description leaves out critical context: the tool can wait for changes, the timeout parameter has no described behavior, and there is no guidance on how this relates to reading vs. listing deliberations. For a tool of this complexity with zero annotations, the description is not complete enough.
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 0%, so the description must compensate. The phrase 'after a sequence cursor' loosely clarifies after_seq, but the description adds no meaning for job_id, limit, wait_for_change, or wait_timeout_seconds. Parameter names hint at their roles, but the description does not explain them.
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 uses a specific verb ('Read') and resource ('job events') with a clear qualifier ('after a sequence cursor'), which conveys an incremental tail operation. It does not explicitly differentiate itself from sibling tools like get_deliberation or list_deliberations, but the cursor-based event reading is a distinct enough purpose.
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?
There is no guidance about when to use this tool versus alternatives, no mention of polling patterns, and no exclusionary context. The description only states what the tool does, leaving the agent to infer usage from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
13 tool updates
v0.1.0-beta.2- First observed
cancel_deliberation - First observed
get_deliberation - First observed
get_quality_metrics - First observed
list_deliberations - First observed
list_models - First observed
list_stale_decisions - First observed
query_decisions - First observed
record_decision_outcome - First observed
resume_deliberation - First observed
review_decision_change - First observed
set_session_models - First observed
start_deliberation - First observed
tail_deliberation
TDQS
B3.2/5.0
Disambiguation4/5
Most tools have clearly distinct purposes: deliberation lifecycle, decision queries, model management, and quality metrics are separated. A few query-style tools like list_deliberations, query_decisions, and list_stale_decisions could be confused at first glance, but their descriptions clarify jobs versus workspace decisions and stale subsets.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern: start_deliberation, list_models, query_decisions, record_decision_outcome, etc. Pluralization is logical based on whether the tool returns multiple items or a single resource.
Tool Count5/5
Thirteen tools is well within the ideal range for this server's scope. The count feels balanced across deliberation job lifecycle, decision workspace operations, and model/quality configuration without unnecessary redundancy.
Completeness4/5
The deliberation lifecycle is well covered with start, list, get, tail, cancel, and resume, and decision operations include query, stale detection, outcome recording, and change review. Minor gaps exist, such as no explicit update or delete operations for decisions and no persistent model configuration, but these are workable.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Durable, shareable and governed project memory with smart triage and explicit project composition.
Hosted runtime for persistent agent teams, durable workflows, memory, schedules, and goals.
Multi-expert decision intelligence with transparent synthesis and auditable workflows.
Durable agent-to-agent handoffs and shared scratchpad for multi-agent workflows.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceAn append-only coordination memory for multi-agent and human work, backed by SQLite, with a local dashboard and acceptance contracts that enforce integrator review before work is considered accepted.1MIT
ellmos-homebase-mcpofficial
AlicenseNot gradedqualityBmaintenanceEnables local-first LLM orchestration with persistent memory, knowledge management, routing, swarm patterns, API probing, tests, automation planning, and plugin discovery via a stdio MCP server, using SQLite for offline storage.2691MIT- AlicenseNot gradedqualityCmaintenanceA production-grade multi-agent workflow orchestrator built on the Model Context Protocol, featuring planner/executor/critic agents, durable run state, and replayable traces.15MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/EngineeredDev/rostra'
If you have feedback or need assistance with the MCP directory API, please join our Discord server