Skip to main content
Glama

start_model_debate

Read-only

Launch a background debate between Claude and Codex to compare independent proposals, cross-examine reasoning, and adjudicate evidence without altering your project.

Instructions

后台启动 Claude 与 Codex 的独立方案、交叉质询和证据裁决;不会修改项目。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYes
roundsNo
contextNo
task_idNo
workspaceNo当前原生聊天所打开工作区的绝对路径;每次调用按当前聊天动态选择,不绑定安装目录。
codex_modelNogpt-5.6-terra
human_ownerNo
claude_modelNosonnet
codex_effortNomedium
claude_effortNomedium

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true and openWorldHint=false, and '不会修改项目' is consistent with that rather than adding new information. '后台启动' (background launch) is the one genuinely additive trait: it tells the agent the call is asynchronous and returns before results exist, though it omits how to retrieve those results.

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?

A single tight sentence with no filler, front-loading the verb and scope before the non-mutation guarantee. Every clause 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?

For a 10-parameter async orchestration tool with no output schema, the description is far too thin: it omits how the background run is tracked or fetched, what the effort/round parameters mean, and what inputs (task vs context vs workspace) are required or optional.

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?

With 10 parameters and only ~10% schema description coverage (just workspace), the description must carry the load, and it does not. 'rounds', 'task_id', 'context', 'human_owner', and both 'claude_effort'/'codex_effort' enums are never explained; only the two model roles are implied by naming Claude and Codex.

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?

States a specific verb (启动/start) plus the resource: a background multi-model debate between Claude and Codex with independent proposals, cross-examination, and evidence adjudication. That distinguishes it from single-model siblings like start_codex_implementation or start_consultation, though it never names those siblings explicitly.

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?

Gives no when-to-use or when-not-to-use guidance and never contrasts with the obvious alternatives (start_consultation, start_workflow, start_codex_implementation). Only an implicit signal that it is a heavyweight, non-mutating analysis run.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.