Multi-model AI debates: GPT-4o, Claude, Gemini & 200+ models discuss, then synthesize insight.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 13 of 13 tools scored. Lowest: 3.2/5.
The tool set separates general consultation (consult-council) from specialized councils for tradeoffs, debugging, architecture, implementation planning, and code review. Session management and utility tools (logs, usage, models, sessions) are clearly distinct. Only minor potential overlap exists between consult-council and the specialized councils, but descriptions clarify the purpose of each.
All tools follow a consistent verb_noun pattern in snake_case (e.g., consult-council, get-session, list-models). Verbs are varied but predictable, and compound nouns are hyphenated consistently. No mixed conventions.
13 tools is appropriate for a platform that offers multiple council workflows plus session, log, and usage management. Each tool addresses a distinct need without unnecessary bloat.
The server covers the full lifecycle of a council-based workflow: model discovery (list-models), execution (consult-council and specialized councils), session retrieval (list-sessions, get-session), sharing (get-thread-link, set-thread-visibility), and operational support (check-usage, get-logs). Missing delete/update session tools are minor and not essential for the core purpose.
assess-tradeoffsAssess TradeoffsAInspectTradeoff assessment council. Pragmatist, Skeptic, and Futurist evaluate options from different angles — short-term vs long-term, risk vs reward, simplicity vs flexibility. Output as pros-cons.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Background context — codebase, team, timeline, constraints | |
| options | No | Specific options to compare | |
| decision | Yes | The decision or question to evaluate | |
| priorities | No | What matters most (e.g., ["performance", "dx", "cost"]) | |
| webhook_url | No | Webhook URL to POST results to after completion | |
| thinking_level | No | Analysis depth | medium |
| session_context | No | Session IDs to use as context (max 3). Prior moderator summaries will be prepended. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-idempotent, non-destructive behavior. The description adds valuable context beyond annotations by explaining the multi-perspective evaluation process and the pros-cons output format, without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and uses a concise metaphor. Every word adds value, and it is perfectly sized for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and full schema descriptions, the description adequately covers the purpose, evaluation angles, and output format. It could slightly expand on how the council metaphor applies in practice, but it is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100%, so the description does not need to explain individual parameters. The description mentions 'options' and 'pros-cons' but does not add significant semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: assessing tradeoffs using a council of three evaluators (Pragmatist, Skeptic, Futurist) and outputting pros and cons. It is specific and distinguishes itself from sibling tools like 'consult-council' by focusing on tradeoff analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: evaluate options from different angles. However, the description does not explicitly state when to use this tool versus alternatives like 'consult-council' or 'plan-implementation', nor does it provide exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check-usageCheck UsageACheck your remaining credits, usage limits, and plan info
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Include detailed per-window rate limit breakdown |
| Name | Required | Description |
|---|---|---|
| plan | Yes | Current plan tier |
| status | Yes | Overall usage status |
| credits | Yes | Remaining credit balance |
| rateLimits | Yes | Rate limit status across all windows |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds valuable context about what data is returned (credits, limits, plan), going beyond the safety hints. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the tool's purpose with zero wasted words. It is concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema available, annotations covering safety), the description sufficiently covers purpose and scope. No additional details are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the sole parameter 'verbose' is fully described in the schema ('Include detailed per-window rate limit breakdown'). The tool description does not need to repeat parameter details, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'check' and names concrete resources (remaining credits, usage limits, plan info). It is distinct from sibling tools like get-logs or list-models, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to know your current credits, limits, or plan details. No explicit alternatives are needed because no sibling tool covers this functionality, and the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consult-councilConsult CouncilAInspectConsult the AI coding council — multiple models discuss your engineering question sequentially (each sees prior responses), then a moderator synthesizes. Auto-mode by default — AI picks optimal models, roles, and conversation mode from your prompt. Provide explicit models to override (manual mode). Fully configurable: mode, format, roles, models, thinking level.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Conversation mode: analyzing (research), brainstorming (ideas), debating (tradeoffs), solving (action plans) | debating |
| roles | No | Inline role names for participants (e.g., ["Security Architect", "Backend Engineer"]) | |
| format | No | Moderator output format: discussion (narrative), adr (architecture decision), comparison (table), pros-cons | discussion |
| models | No | Override specific model IDs. Min 3 models. Use list-models to see available options | |
| prompt | Yes | The question, topic, or problem to debate | |
| context | No | Additional background context for the debate (code, docs, requirements) | |
| knowledge | No | Reference knowledge to inject as context | |
| auto_route | No | Auto-select optimal models based on prompt analysis and historical performance | |
| webhook_url | No | Webhook URL to POST results to after completion | |
| thinking_level | No | Controls model quality and cost: low (fast/cheap), medium (balanced), high (maximum reasoning) | medium |
| session_context | No | Session IDs to use as context (max 3). Prior moderator summaries will be prepended. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: sequential discussion, moderator synthesis, auto-mode vs manual mode, and full configurability. This goes beyond the annotations (readOnlyHint=false, openWorldHint=true) to explain the actual workflow and side effects, such as the fact that multiple AI models will be invoked in sequence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the core concept ('Consult the AI coding council...'). The final sentence 'Fully configurable...' is somewhat redundant as it repeats parameters already listed, but it is not verbose enough to be a significant issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters and no output schema, the description provides sufficient high-level context: it explains the discussion flow, synthesis, auto/manual modes, and configurability. It does not explicitly describe the return value (e.g., a synthesized summary), but the phrase 'a moderator synthesizes' implies the output. Additional details about knowledge injection or webhooks are not mentioned, but those are niche parameters documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description adds minimal extra meaning beyond what the schema provides, merely listing parameter names (mode, format, roles, models, thinking level) in the last sentence. It does reference auto-mode and manual override, which maps to the auto_route parameter, but this is already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Consult') and resource ('AI coding council'), and explains the process (models discuss sequentially, moderator synthesizes). It distinguishes itself from sibling tools by focusing on multi-model consultation, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use (engineering questions) and explains the default auto-mode versus manual override. However, it does not explicitly state when not to use this tool or name alternative tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
debug-issueDebug IssueBInspectDebugging council. Root Cause Analyst, Systems Engineer, and Edge Case Investigator collaboratively diagnose bugs, analyze errors, and propose fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | The relevant code where the bug occurs | |
| error | No | Error message, stack trace, or unexpected output | |
| problem | Yes | Describe the bug, failure, or unexpected behavior | |
| knowledge | No | Reference knowledge to inject as context | |
| webhook_url | No | Webhook URL to POST results to after completion | |
| thinking_level | No | Analysis depth | medium |
| session_context | No | Session IDs to use as context (max 3). Prior moderator summaries will be prepended. | |
| expected_behavior | No | What should happen vs what actually happens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, non-idempotent, and open-world behavior. The description adds collaborative council context and role names, but does not disclose side effects like webhook delivery, session_context handling, or knowledge fetching. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with 'Debugging council,' and includes role names that add value without fluff. It avoids repetition of schema details and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description is too sparse. It does not describe what a result looks like, how webhook_url or session_context affect execution, or the overall process. This is a significant gap for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so the description does not need to add much. It does not mention parameter-specific semantics beyond the schema, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'diagnose bugs, analyze errors, and propose fixes' via a 'debugging council' with specific roles. This distinguishes it from siblings like review-code or plan-implementation. It is not a tautology and uses specific verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not state prerequisites like providing code/error/problem, nor does it exclude cases better suited for other tools. The intended use is only implied by the word 'debugging'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
design-architectureDesign ArchitectureBInspectArchitecture design council. Systems Architect, Infrastructure Engineer, and DX Advocate evaluate your system design. Always uses high thinking for maximum depth. Output as ADR.
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | Target scale: startup (small team), growth (scaling), enterprise (large org) | startup |
| tech_stack | No | Preferred technologies | |
| description | Yes | What the system should do | |
| focus_areas | No | Priority areas (e.g., ["security", "performance"]) | |
| webhook_url | No | Webhook URL to POST results to after completion |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, open-world, non-idempotent, and non-destructive behavior. The description adds context about the multi-persona evaluation ('Systems Architect, Infrastructure Engineer, DX Advocate'), the use of 'high thinking for maximum depth,' and the ADR output format. However, it does not disclose potential side effects like the webhook POST behavior, which is relevant given 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with four short sentences each adding distinct information: the council concept, the evaluating roles, the high-thinking behavior, and the ADR output. It is front-loaded with purpose, though 'Always uses high thinking for maximum depth' is slightly marketing-driven and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description appropriately mentions 'Output as ADR,' but it lacks further detail about the ADR structure or the evaluation process. It also does not mention the webhook_url parameter's behavior (posting results), which is a notable gap. Overall, it is minimally complete but misses some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all five parameters, so the baseline is 3. The tool description does not add any additional parameter semantics beyond what the schema already offers, which is acceptable given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is an 'Architecture design council' where three expert roles evaluate a system design, with output as an ADR. This conveys a specific verb (evaluate) and resource (system design), though it could more explicitly distinguish itself from sibling tools like 'consult-council' or 'assess-tradeoffs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a system design to be evaluated by an architecture council, but it does not explicitly state when to use this tool vs alternatives or mention any exclusions. It provides no comparative guidance against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-logsGet LogsAQuery structured logs from your MCP tool executions. Filter by session, severity level, event type, and time range. Useful for debugging and monitoring tool usage.
| Name | Required | Description | Default |
|---|---|---|---|
| event | No | Filter by event name (e.g., "debate_completed") | |
| level | No | Filter by log level | |
| limit | No | Max results | |
| offset | No | Pagination offset | |
| end_time | No | End timestamp (ms) for time range filter | |
| session_id | No | Filter logs for a specific session | |
| start_time | No | Start timestamp (ms) for time range filter |
| Name | Required | Description |
|---|---|---|
| logs | Yes | Matching log entries |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds little behavioral context beyond the resource type and filters; it does not mention pagination behavior, ordering, or other operational details. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and resource, and follows with a compact list of filters and a use case. Every sentence serves a purpose with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only log query tool with a rich schema, output schema, and annotations, the description adequately covers the resource, filters, and use case. It does not explain return values (handled by output schema) and does not need to describe every filter detail since the schema does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description mentions 'session, severity level, event type, and time range,' which maps to session_id, level, event, and start/end_time, but this adds minimal value beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and resource ('structured logs from your MCP tool executions'), which is clear and distinguishes it from generic logging tools. However, it does not explicitly differentiate from sibling tools like 'debug-issue' or 'get-session', so it falls 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an implied use case ('Useful for debugging and monitoring tool usage') but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. This is minimal guidance, landing at a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-sessionGet SessionAGet full details of a previous MCP session by ID. Returns the complete result including participant responses and moderator synthesis. Use list-sessions first to find session IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID to retrieve |
| Name | Required | Description |
|---|---|---|
| id | Yes | Session identifier |
| prompt | Yes | Original prompt text |
| toolName | Yes | Tool that was invoked |
| createdAt | Yes | Session creation timestamp |
| durationMs | Yes | Duration in milliseconds |
| qualityScore | Yes | AI-rated quality score |
| totalCredits | Yes | Total credits consumed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by specifying the return content (participant responses and moderator synthesis), though it doesn't mention error behavior or not-found cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose and return value, with a useful prerequisite note. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with strong annotations and an output schema, the description covers purpose, return contents, and how to find the ID. It is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'session_id' with a description, so the description adds minimal extra semantic value. The phrase 'by ID' reaffirms the schema but does not enrich it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get full details') and resource ('previous MCP session by ID'), distinguishing it from the sibling tool 'list-sessions' which lists sessions. It also states what the result contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use 'list-sessions first to find session IDs', providing clear sequencing and pointing to the alternative tool. This is direct when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-thread-linkGet Thread LinkAGet the dashboard URL for a previous debate session. Returns the thread link and public URL if the thread is public.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID to get the thread link for |
| Name | Required | Description |
|---|---|---|
| isPublic | Yes | Whether the thread is publicly accessible |
| publicUrl | Yes | Public share URL if thread is public |
| dashboardUrl | Yes | Dashboard URL to view the thread |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context by specifying the return value: 'Returns the thread link and public URL if the thread is public.' This clarifies the conditional nature of the public URL, going beyond the annotation defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the verb and resource, followed by return-value detail. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, complete schema coverage, and an output schema, the description is fully sufficient. It states what the tool does, what it returns, and the public/private condition, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'session_id' with a clear description. The tool description adds minimal extra meaning, only positioning the session as 'previous debate session.' Since schema coverage is complete, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the dashboard URL for a previous debate session.' It names a specific verb ('Get') and resource ('dashboard URL'), and distinguishes it from sibling tools like 'get-session' by focusing on link retrieval rather than general session data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for retrieving a link to a previous debate session. However, it does not explicitly state when to prefer this over alternatives like 'get-session', nor does it mention any conditions or exclusions beyond noting the public URL is returned only if the thread is public.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-modelsList ModelsAList available AI models grouped by thinking level (low/medium/high). Shows default models, credit costs, capabilities for each tier. Use this before consult to understand model options.
| Name | Required | Description | Default |
|---|---|---|---|
| thinking_level | No | Filter to a specific thinking level |
| Name | Required | Description |
|---|---|---|
| levels | Yes | Available thinking level tiers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent. The description adds valuable context by explaining the grouping by thinking level and the type of information returned (credit costs, capabilities), which goes beyond the structured annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by key output details and a usage pointer. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema, the description fully covers purpose, content, and usage context. It sufficiently complements the schema and annotations, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the sole parameter is 100%, so the schema documents it fully. The description mentions 'thinking level' but does not add new semantic details beyond what the schema and enum already provide, which aligns with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available AI models grouped by thinking level, with specific details on what is shown (default models, credit costs, capabilities). It distinguishes itself from all sibling tools by focusing on model listing rather than sessions or code operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool 'before consult', providing a clear context for when to invoke it. It does not enumerate exclusions or alternatives, but the single usage hint is actionable and sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-sessionsList SessionsAList your previous MCP tool sessions. Returns session metadata including prompt, tool used, quality score, and credits consumed. Useful for reviewing past council discussions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return | |
| offset | No | Pagination offset | |
| tool_name | No | Filter by tool name (e.g., "consult", "architect") |
| Name | Required | Description |
|---|---|---|
| hasMore | Yes | Whether more results are available |
| sessions | Yes | List of sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond that, such as the historical scope ('previous') and the type of metadata returned. This is sufficient but not rich, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, with the main action front-loaded and the second sentence providing valuable context. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and full schema coverage, the description is largely complete. It provides the essential purpose, a usage context, and the nature of the data returned. It could improve by explicitly naming alternatives (e.g., get-session), but this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (limit, offset, tool_name) fully described in the input schema. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('your previous MCP tool sessions'), and it specifies what is returned (session metadata including prompt, tool used, quality score, credits consumed). This distinguishes it from siblings like get-session, which focuses on a single session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('Useful for reviewing past council discussions'), giving context for when to use the tool. However, it does not explicitly mention alternative tools or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan-implementationPlan ImplementationAInspectImplementation planning council. Tech Lead, Senior Engineer, and QA Strategist break down a feature into actionable steps, identify risks, and define acceptance criteria. Output as ADR.
| Name | Required | Description | Default |
|---|---|---|---|
| feature | Yes | The feature or change to plan | |
| knowledge | No | Reference knowledge to inject as context | |
| tech_stack | No | Current tech stack | |
| constraints | No | Constraints (e.g., ["no breaking changes", "must support offline"]) | |
| webhook_url | No | Webhook URL to POST results to after completion | |
| thinking_level | No | Planning depth | medium |
| session_context | No | Session IDs to use as context (max 3). Prior moderator summaries will be prepended. | |
| codebase_context | No | Relevant existing code, file structure, or architecture notes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-idempotent, non-destructive, and open-world behavior. The description adds that output is an ADR but does not disclose side effects such as webhook POSTing or other external actions, which would be useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and about 30 words, with no unnecessary detail. It front-loads the council concept and clearly states the output format, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and output, and parameter details are well-covered by the schema. It omits behavioral aspects like webhook usage, but those are present in the schema descriptions. Overall, it is adequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: a council of roles breaks down a feature into actionable steps, identifies risks, and defines acceptance criteria, output as an ADR. This is a specific verb+resource statement that differentiates it from sibling tools like design-architecture or consult-council.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for implementation planning, implying when to use it. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review-codeReview CodeAInspectCode review council. Senior Engineer, Security Reviewer, and Performance Analyst analyze your code and a moderator synthesizes their findings.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code to review | |
| focus | No | Review focus areas (e.g., ["security", "performance"]) | |
| language | No | Programming language (auto-detected if not specified) | |
| webhook_url | No | Webhook URL to POST results to after completion | |
| thinking_level | No | Review depth: low (quick scan), medium (balanced), high (thorough) | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the multi-reviewer process and moderator synthesis, which is beyond the annotations. However, it does not disclose important behavioral traits such as asynchronous completion via webhook or external processing, leaving gaps that the schema only partially covers. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and immediately communicates the tool's nature as a 'Code review council,' with no filler. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's complexity (optional focus, language, webhook, thinking level) is not addressed in the description, and no output schema exists to explain return values. While the schema compensates for parameters, the description leaves ambiguity about how results are delivered, especially with the webhook option. Still, the core purpose is clear enough for a basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are fully described in the input schema (100% coverage), so the description need not repeat them. The description adds no parameter-specific semantics, but the schema's descriptions for 'code', 'focus', 'language', 'webhook_url', and 'thinking_level' are sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes code using multiple specialized reviewers and synthesizes findings, with 'analyze your code' as the specific verb+resource. It distinguishes itself from siblings like 'consult-council' by framing itself as a code review council with distinct roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'consult-council' or 'debug-issue.' The description only implies usage for code review through the 'Code review council' framing, giving context but not exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set-thread-visibilitySet Thread VisibilityASet a thread as public or private. Public threads can be shared via URL. Use session_id from a previous debate session.
| Name | Required | Description | Default |
|---|---|---|---|
| is_public | Yes | Set to true to make the thread publicly accessible, false to make it private | |
| session_id | Yes | The session ID from a previous debate |
| Name | Required | Description |
|---|---|---|
| isPublic | Yes | Current visibility state |
| publicUrl | Yes | Public share URL if thread is public |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that the operation is not read-only, not destructive, and idempotent. The description adds useful context about public threads being shareable via URL, which is a behavioral consequence. However, it doesn't detail other effects like reversal or immediate propagation, but given the annotations, the baseline bar is met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no fluff. Every sentence serves a purpose: stating the action and clarifying a prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with full schema coverage and an output schema, the description is complete. It provides the core behavior, the prerequisite, and a practical implication (URL sharing), without requiring excessive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions, so baseline is 3. The description adds meaning by linking is_public to the public/private states and clarifying that session_id comes from a previous debate session, which reinforces and enriches the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set a thread as public or private.' It identifies the specific resource (thread visibility) and the two possible states, and adds the contextual note that public threads can be shared via URL. This clearly distinguishes it from sibling tools like get-thread-link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to change a thread's visibility, and it specifies that session_id must come from a previous debate session. However, it does not explicitly mention alternatives or when not to use this tool, such as referencing get-thread-link for retrieving the link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!