model-council-mcp-codex

Server Quality Checklist

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

Latest release: v0.2.80
Disambiguation4/5
Most tools have clearly distinct purposes, but setup_council and configure_council both modify council configuration, and get_council_config and council_status both report council members. Descriptions clarify the boundaries, so ambiguity is low but not zero.
Naming Consistency4/5
Tool names mostly follow a verb_noun pattern (list_models, configure_council, ask_council, get_council_result, set_council_timeouts), but council_status is a noun phrase and deviates. The overall convention is consistent enough to be predictable.
Tool Count5/5
9 tools is well-scoped for a model council management server. Each tool covers a necessary part of the lifecycle: discovery, setup, configuration, synchronous/asynchronous querying, result retrieval, status, and timeout management.
Completeness5/5
The tool surface provides full lifecycle coverage for a model council: list available models, set up and configure the council, ask questions synchronously or asynchronously, retrieve results, check status, and adjust timeouts. No critical operations are missing.
Average 4.4/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 125 commits in the last 12 weeks
- Last stable release on August 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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.
Add a glama.json file to provide metadata about your server.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds value by explaining the status values (running | done | error), that full result comes when done, and that listing returns metadata only. No contradiction with annotations exists.
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?
Two sentences, front-loaded with the primary purpose, then a compact breakdown of the two usage modes. Every word earns its place; no fluff or redundancy.
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?
Without an output schema, the description discloses key return aspects (status values, full result when done). It fully explains both invocation modes and remains focused. It could mention error semantics more deeply, but given the tool's simplicity and the presence of a sibling for status, this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both list and job_id. The description adds semantic nuance by clarifying the relationship: omitting job_id is equivalent to setting list=true, and the default behavior (omit both) results in listing recent jobs. This extra integration goes beyond the schema.
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 states a specific verb ('Fetch') with a clear resource ('background council run started with ask_council_async'). It distinguishes from siblings by mentioning the async origin and explicitly describing two usage modes (fetch by job_id or list recent jobs), which separates it from ask_council or council_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use when you have a job_id from ask_council_async, or omit job_id/list to see recent jobs. It does not explicitly name alternative tools or say when to avoid this tool, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful context: enumerates all providers (API-key and CLI-based) and states the output is model IDs for use with configure_council. No contradiction, but it doesn't mention potential provider errors or pagination behavior.
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?
Two sentences, front-loaded with the action and scope, followed by an actionable next step. Every word earns its place with no filler.
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?
The tool is simple with one optional parameter and no output schema; the description gives provider scope and integration context. It doesn't explicitly specify the return format, but 'returned model IDs' is sufficient for an agent to invoke it correctly.
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?
The schema fully covers the only parameter (filter_provider) with a list of allowed values. The description does not add additional semantics beyond the schema, so the baseline of 3 applies.
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'), names the resource ('AI models'), and specifies scope ('across every configured provider' with an explicit list). It clearly differentiates from sibling configuration/query tools as the discovery operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to discover available models, explicitly stating to use the returned model IDs when calling configure_council. It doesn't state exclusions or alternatives, but the context among siblings is clear enough.
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?
The readOnlyHint annotation already signals a safe, read-only operation. The description adds the specific data fields returned but does not disclose any potential edge cases like whether defaults are shown or if an error occurs when no council is configured. 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 a single, front-loaded sentence that directly states the verb and resource. It avoids extraneous words and fully conveys the tool's purpose and return content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, readOnlyHint present), the description fully covers what the tool does and what it returns. The list of fields is sufficient for an agent to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description need not explain parameter syntax. The baseline of 4 for no-parameter tools applies, and the description's enumeration of return fields provides additional context beyond the empty schema.
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 clearly states the tool returns the current council configuration and enumerates the exact components (member models, judge model, response mode, max deconfliction rounds). This distinguishes it from siblings like list_models (which lists models) and configure_council (which modifies configuration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is self-evident as a getter, implying use when you need to inspect the current configuration. However, it does not explicitly contrast with siblings like configure_council or set_council_timeouts, so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the in-memory nature and lifecycle ('Jobs are in-memory and do not survive a server reload'), which is critical behavioral context beyond the minimal annotations. It also clarifies the return behavior (job_id) and that it's non-blocking.
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?
Three sentences, with the primary action stated upfront. Each sentence adds distinct information: purpose, input compatibility, and fetch mechanism, plus a caveat. No redundant phrasing.
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?
The description covers the full workflow: start background job, get job_id, poll result, and job lifetime. It references sibling tools for parameter details and result retrieval, which is sufficient given the schema and sibling context. Minor omission of error handling or timeout behavior, but not critical.
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?
The schema already covers all 11 parameters with descriptions (100% coverage), so the description doesn't need to repeat them. It adds value by stating 'Same inputs as ask_council', which informs the agent that parameter behavior is consistent with a known sibling. No additional semantics are provided.
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 clearly states the tool 'Start a council run in the background and return a job_id immediately', identifying the specific verb and resource. It also differentiates from siblings by referencing ask_council for synchronous behavior and get_council_result for polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it: 'so a long deconfliction/dialectic run (or a slow local model) does not block', providing a clear use case. It also instructs how to retrieve results: 'Poll get_council_result with the job_id'. It doesn't explicitly state exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already declares the read-only nature, and the description adds meaningful context: it reports specific environmental checks (Ollama cloud reachability, login states, Grok CLI fail-closed, quota warnings) and portability across clients/install methods. No contradiction detected.
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 long and densely packed with specific, useful information. It is front-loaded with the core action ('Report the detected environment and current setup') and then enumerates the exact contents. Every clause earns its place without unnecessary fluff.
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?
Without an output schema, the description carries the burden of explaining what the tool returns, and it lists the major categories (models, cloud reachability, login status, council members, tiers, concurrency, quota). It is sufficiently complete for a 0-parameter read-only status tool, though it does not detail the exact output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which the input schema fully reflects. Per the rubric, a no-parameter tool gets a baseline of 4 because the description does not need to explain parameter meanings. The description adds no parameter info, which is appropriate.
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 ('Report') and names the resource ('detected environment and current setup') with a detailed list of contents. It clearly distinguishes this from siblings like list_models and configure_council by positioning it as the welcome/status readout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it as the 'welcome/status readout' and notes it works in every client and install method. It provides clear context but does not explicitly mention alternatives or when not to use it, though the sibling tools imply the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only set readOnlyHint=false. The description adds behavioral details: persistence of choices across reloads, reload requirement for new providers/concurrency changes, and the action of re-detecting/auto-populating. This goes beyond the annotation without contradicting it, though it does not detail side effects like overwriting existing council contents.
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 three sentences: the first states the core action, the second enumerates tier options per provider (which is helpful), and the third gives a critical reload caveat. No filler, well structured, and front-loaded.
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?
Given it's a setup tool with no output schema, the description adequately covers the action, persistence effect, and reload requirement. It could mention what happens to existing council entries, but overall it is complete enough for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes each parameter at 100% coverage with enums. The description adds meaning by stating that 'Tiers gate cloud availability and per-provider concurrency,' which explains the purpose of the tier values beyond simply listing them. It also indicates persistence, enriching the semantics.
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 clearly states the tool's function: 'Set subscription tiers, then re-detect and auto-populate the council with everything usable.' It names the resource (council) and distinguishes itself from the sibling 'configure_council' by emphasizing re-detection and auto-population, with concrete provider/tier lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, noting that choices persist across reloads and that registering a new provider or changing concurrency requires a reload. It implies this is the setup tool for tiers, but it does not explicitly mention when to use it over 'configure_council' or any exclusions, so it lacks full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal readOnlyHint annotation, the description richly discloses behavior: deconfliction's iterative loop and 0–100% score, pooled's 'no winner is forced' divergence preservation, dialectic's thesis/antithesis/synthesis flow, vision routing, local `git diff` execution, and provider-specific full_repo_access sandbox limitations. This is far more than annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a long single paragraph, but it is front-loaded with the primary purpose and every sentence carries operational weight. Given the tool's genuine complexity (11 parameters, 5 modes, multiple safety caveats), the length is justified, though bulleted structure would improve scannability.
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?
With no output schema, the description covers key result-related context (visionRouting, deconfliction score, structured response) and all major input behaviors and safety warnings. It does not fully specify the overall response envelope, but for this complex tool the contextual coverage is strong and sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% parameter coverage, the description adds substantial meaning: it explains each mode's output semantics, contrasts git_ref with files, details vision capabilities and caps, clarifies reasoning_effort clamping behavior, and warns about full_repo_access provider differences. These are semantics the schema enum/descriptions do not convey.
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 opening sentence is specific and action-oriented: 'Send a question to the model council and get a structured response,' and the mode enumeration clarifies the tool's scope. It differentiates from list/configuration siblings, but does not explicitly distinguish itself from the closely related ask_council_async, leaving the synchronous-versus-asynchronous choice implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Attach images to ask a vision question,' 'For a repo review, pass git_ref instead of hand-listing files,' and 'For a full repo-wide review (not just a diff), full_repo_access.' It also provides a when-not caveat ('confirm with the user before setting true') and clarifies that vision-incapable members are skipped, giving clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are minimal (readOnlyHint=false), so the description carries the behavioral disclosure burden and does so extensively. It discloses persistence across restarts/reloads, partial-update semantics, validation of judge_model (rejecting unparseable values), default behavior for auto_council, and reasoning_effort clamping across mixed councils. This is far beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose and then adds behavioral details. Every clause provides necessary context, and there is no redundant or filler content. It is appropriately concise for a tool with six parameters.
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?
Given the tool's complexity (6 parameters, no output schema, rich validation rules), the description is quite thorough. It covers the update semantics, persistence, partial updates, and subtle behaviors like judge_model auto and reasoning_effort clamping. It does not explicitly describe return values, but since there is no output schema, this is a minor gap; the core invocation context is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed parameter descriptions, setting a baseline of 3. The description adds extra meaning by explaining that each field is persisted and that unset fields are untouched, which applies to all parameters. It also introduces cross-parameter semantics like auto_council interacting with models and reasoning_effort overriding, which the schema does not capture.
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 clearly states the tool's purpose: "Update the council configuration" and enumerates the specific editable aspects (models, judge, response mode, deconfliction rounds). It distinguishes itself from siblings like setup_council and get_council_config by using the verb "update" and by mentioning persistence relative to setup_council.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: it is an update operation on existing council configuration. It explicitly states that "a field left unset is untouched," which is valuable partial-update guidance. It does not explicitly rule out setup_council, but the sibling names and the phrase "same as setup_council's tier choices" give a clear sense of the intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=false, the description discloses persistence across reloads, effect timing ('takes effect on the next ask_council'), the fact that a reload is NOT required, and the return value ('Returns the now-effective values'). It also explains the timeoutNotice signal, providing rich behavioral context.
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?
Five sentences, each informative and non-redundant. The main action and key scope are front-loaded ('Set the per-completion wall-clock timeouts'), and every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description fully covers persistence, effect timing, when to raise timeouts, and the return behavior. The lack of an output schema is mitigated by the explicit return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive defaults and ranges, but the description adds meaning by linking each parameter to its use case (run_timeout_ms for text-only, repo_timeout_ms for full_repo_access) and clarifying omission semantics. This goes beyond the schema's baseline, though the schema already does heavy lifting.
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 clearly states the action ('Set') and the resource ('per-completion wall-clock timeouts for council calls'), specifies units, and distinguishes between two timeout types (text-only vs repo-access). It also notes persistence and override of env defaults, differentiating it from sibling config tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly gives a concrete trigger: 'Raise these when a member answer is cut mid-generation', and explains the partial-update behavior ('Omit either to leave it unchanged'). However, it does not explicitly name alternatives or state when not to use this tool, but the context strongly implies its niche.
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:

[![model-council-mcp-codex MCP server](https://glama.ai/mcp/servers/tsarihan/model-council-mcp-codex/badges/card.svg)](https://glama.ai/mcp/servers/tsarihan/model-council-mcp-codex)

Score Badge

Copy to your README.md:

[![model-council-mcp-codex MCP server](https://glama.ai/mcp/servers/tsarihan/model-council-mcp-codex/badges/score.svg)](https://glama.ai/mcp/servers/tsarihan/model-council-mcp-codex)

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/tsarihan/model-council-mcp-codex'

If you have feedback or need assistance with the MCP directory API, please join our Discord server