rostra

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0-beta.2
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.
Average 2.8/5 across 13 of 13 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![rostra MCP server](https://glama.ai/mcp/servers/EngineeredDev/rostra/badges/card.svg)](https://glama.ai/mcp/servers/EngineeredDev/rostra)

Score Badge

Copy to your README.md:

[![rostra MCP server](https://glama.ai/mcp/servers/EngineeredDev/rostra/badges/score.svg)](https://glama.ai/mcp/servers/EngineeredDev/rostra)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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