Which integrations are available for this server?

Allows using Google's Gemini models for extended reasoning and vision capabilities. Allows using local models via Ollama for privacy and offline use. Allows using OpenAI's GPT and O3 models for deep thinking and code reviews.

How do I use PAL MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PAL MCP Server Use consensus with gpt-5 and gemini-pro to decide: dark mode or offline support next" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

PAL MCP Server

by bigl34

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

PAL MCP: Many Workflows. One Context.

Your AI's PAL – a Provider Abstraction Layer Formerly known as Zen MCP

PAL in action

👉 Watch more examples

Your CLI + Multiple Models = Your AI Dev Team

Use the 🤖 CLI you love:
Claude Code · Gemini CLI · Codex CLI · Qwen Code CLI · Cursor · and more

With multiple models within a single prompt:
Gemini · OpenAI · Anthropic · Grok · Azure · Ollama · OpenRouter · DIAL · On-Device Model

🆕 Now with CLI-to-CLI Bridge

The new clink (CLI + Link) tool connects external AI CLIs directly into your workflow:

Connect external CLIs like Gemini CLI, Codex CLI, and Claude Code directly into your workflow
CLI Subagents - Launch isolated CLI instances from within your current CLI! Claude Code can spawn Codex subagents, Codex can spawn Gemini CLI subagents, etc. Offload heavy tasks (code reviews, bug hunting) to fresh contexts while your main session's context window remains unpolluted. Each subagent returns only final results.
Context Isolation - Run separate investigations without polluting your primary workspace
Role Specialization - Spawn planner, codereviewer, or custom role agents with specialized system prompts
Full CLI Capabilities - Web search, file inspection, MCP tool access, latest documentation lookups
Seamless Continuity - Sub-CLIs participate as first-class members with full conversation context between tools

# Codex spawns Codex subagent for isolated code review in fresh context
clink with codex codereviewer to audit auth module for security issues
# Subagent reviews in isolation, returns final report without cluttering your context as codex reads each file and walks the directory structure

# Consensus from different AI models → Implementation handoff with full context preservation between tools
Use consensus with gpt-5 and gemini-pro to decide: dark mode or offline support next
Continue with clink gemini - implement the recommended feature
# Gemini receives full debate context and starts coding immediately

👉 Learn more about clink

Related MCP server: MCP Boilerplate

Why PAL MCP?

Why rely on one AI model when you can orchestrate them all?

A Model Context Protocol server that supercharges tools like Claude Code, Codex CLI, and IDE clients such as Cursor or the Claude Dev VS Code extension. PAL MCP connects your favorite AI tool to multiple AI models for enhanced code analysis, problem-solving, and collaborative development.

True AI Collaboration with Conversation Continuity

PAL supports conversation threading so your CLI can discuss ideas with multiple AI models, exchange reasoning, get second opinions, and even run collaborative debates between models to help you reach deeper insights and better solutions.

Your CLI always stays in control but gets perspectives from the best AI for each subtask. Context carries forward seamlessly across tools and models, enabling complex workflows like: code reviews with multiple models → automated planning → implementation → pre-commit validation.

You're in control. Your CLI of choice orchestrates the AI team, but you decide the workflow. Craft powerful prompts that bring in Gemini Pro, GPT 5, Flash, or local offline models exactly when needed.

A typical workflow with Claude Code as an example:

Multi-Model Orchestration - Claude coordinates with Gemini Pro, O3, GPT-5, and 50+ other models to get the best analysis for each task
Context Revival Magic - Even after Claude's context resets, continue conversations seamlessly by having other models "remind" Claude of the discussion
Guided Workflows - Enforces systematic investigation phases that prevent rushed analysis and ensure thorough code examination
Extended Context Windows - Break Claude's limits by delegating to Gemini (1M tokens) or O3 (200K tokens) for massive codebases
True Conversation Continuity - Full context flows across tools and models - Gemini remembers what O3 said 10 steps ago
Model-Specific Strengths - Extended thinking with Gemini Pro, blazing speed with Flash, strong reasoning with O3, privacy with local Ollama
Professional Code Reviews - Multi-pass analysis with severity levels, actionable feedback, and consensus from multiple AI experts
Smart Debugging Assistant - Systematic root cause analysis with hypothesis tracking and confidence levels
Automatic Model Selection - Claude intelligently picks the right model for each subtask (or you can specify)
Vision Capabilities - Analyze screenshots, diagrams, and visual content with vision-enabled models
Local Model Support - Run Llama, Mistral, or other models locally for complete privacy and zero API costs
Bypass MCP Token Limits - Automatically works around MCP's 25K limit for large prompts and responses

The Killer Feature: When Claude's context resets, just ask to "continue with O3" - the other model's response magically revives Claude's understanding without re-ingesting documents!

Example: Multi-Model Code Review Workflow

Perform a codereview using gemini pro and o3 and use planner to generate a detailed plan, implement the fixes and do a final precommit check by continuing from the previous codereview
This triggers a codereview workflow where Claude walks the code, looking for all kinds of issues
After multiple passes, collects relevant code and makes note of issues along the way
Maintains a confidence level between exploring, low, medium, high and certain to track how confidently it's been able to find and identify issues
Generates a detailed list of critical -> low issues
Shares the relevant files, findings, etc with Gemini Pro to perform a deep dive for a second codereview
Comes back with a response and next does the same with o3, adding to the prompt if a new discovery comes to light
When done, Claude takes in all the feedback and combines a single list of all critical -> low issues, including good patterns in your code. The final list includes new findings or revisions in case Claude misunderstood or missed something crucial and one of the other models pointed this out
It then uses the planner workflow to break the work down into simpler steps if a major refactor is required
Claude then performs the actual work of fixing highlighted issues
When done, Claude returns to Gemini Pro for a precommit review

All within a single conversation thread! Gemini Pro in step 11 knows what was recommended by O3 in step 7! Taking that context and review into consideration to aid with its final pre-commit review.

Think of it as Claude Code for Claude Code. This MCP isn't magic. It's just super-glue.

Remember: Claude stays in full control — but YOU call the shots. PAL is designed to have Claude engage other models only when needed — and to follow through with meaningful back-and-forth. You're the one who crafts the powerful prompt that makes Claude bring in Gemini, Flash, O3 — or fly solo. You're the guide. The prompter. The puppeteer.
You are the AI - Actually Intelligent.

Recommended AI Stack

For best results when using Claude Code:

Sonnet 4.5 - All agentic work and orchestration
Gemini 3.0 Pro OR GPT-5.2 / Pro - Deep thinking, additional code reviews, debugging and validations, pre-commit analysis

For best results when using Codex CLI:

GPT-5.2 Codex Medium - All agentic work and orchestration
Gemini 3.0 Pro OR GPT-5.2-Pro - Deep thinking, additional code reviews, debugging and validations, pre-commit analysis

Quick Start (5 minutes)

Prerequisites: Python 3.10+, Git, uv installed

1. Get API Keys (choose one or more):

OpenRouter - Access multiple models with one API
Gemini - Google's latest models
OpenAI - O3, GPT-5 series
Azure OpenAI - Enterprise deployments of GPT-4o, GPT-4.1, GPT-5 family
X.AI - Grok models
DIAL - Vendor-agnostic model access
Ollama - Local models (free)

2. Install (choose one):

Option A: Clone and Automatic Setup (recommended)

git clone https://github.com/BeehiveInnovations/pal-mcp-server.git
cd pal-mcp-server

# Handles everything: setup, config, API keys from system environment. 
# Auto-configures Claude Desktop, Claude Code, Gemini CLI, Codex CLI, Qwen CLI
# Enable / disable additional settings in .env
./run-server.sh

Option B: Instant Setup with uvx

// Add to ~/.claude/settings.json or .mcp.json
// Don't forget to add your API keys under env
{
  "mcpServers": {
    "pal": {
      "command": "bash",
      "args": ["-c", "for p in $(which uvx 2>/dev/null) $HOME/.local/bin/uvx /opt/homebrew/bin/uvx /usr/local/bin/uvx uvx; do [ -x \"$p\" ] && exec \"$p\" --from git+https://github.com/BeehiveInnovations/pal-mcp-server.git pal-mcp-server; done; echo 'uvx not found' >&2; exit 1"],
      "env": {
        "PATH": "/usr/local/bin:/usr/bin:/bin:/opt/homebrew/bin:~/.local/bin",
        "GEMINI_API_KEY": "your-key-here",
        "DISABLED_TOOLS": "analyze,refactor,testgen,secaudit,docgen,tracer",
        "DEFAULT_MODEL": "auto"
      }
    }
  }
}

3. Start Using!

"Use pal to analyze this code for security issues with gemini pro"
"Debug this error with o3 and then get flash to suggest optimizations"
"Plan the migration strategy with pal, get consensus from multiple models"
"clink with cli_name=\"gemini\" role=\"planner\" to draft a phased rollout plan"

👉 Complete Setup Guide with detailed installation, configuration for Gemini / Codex / Qwen, and troubleshooting 👉 Cursor & VS Code Setup for IDE integration instructions 📺 Watch tools in action to see real-world examples

Provider Configuration

PAL activates any provider that has credentials in your .env. See .env.example for deeper customization.

Core Tools

Note: Each tool comes with its own multi-step workflow, parameters, and descriptions that consume valuable context window space even when not in use. To optimize performance, some tools are disabled by default. See Tool Configuration below to enable them.

Collaboration & Planning (Enabled by default)

clink - Bridge requests to external AI CLIs (Gemini planner, codereviewer, etc.)
chat - Brainstorm ideas, get second opinions, validate approaches. With capable models (GPT-5.2 Pro, Gemini 3.0 Pro), generates complete code / implementation
thinkdeep - Extended reasoning, edge case analysis, alternative perspectives
planner - Break down complex projects into structured, actionable plans
consensus - Get expert opinions from multiple AI models with stance steering

Code Analysis & Quality

debug - Systematic investigation and root cause analysis
precommit - Validate changes before committing, prevent regressions
codereview - Professional reviews with severity levels and actionable feedback
analyze (disabled by default - enable) - Understand architecture, patterns, dependencies across entire codebases

Development Tools (Disabled by default - enable)

refactor - Intelligent code refactoring with decomposition focus
testgen - Comprehensive test generation with edge cases
secaudit - Security audits with OWASP Top 10 analysis
docgen - Generate documentation with complexity analysis

Utilities

apilookup - Forces current-year API/SDK documentation lookups in a sub-process (saves tokens within the current context window), prevents outdated training data responses
challenge - Prevent "You're absolutely right!" responses with critical analysis
tracer (disabled by default - enable) - Static analysis prompts for call-flow mapping

Default Configuration

To optimize context window usage, only essential tools are enabled by default:

Enabled by default:

chat, thinkdeep, planner, consensus - Core collaboration tools
codereview, precommit, debug - Essential code quality tools
apilookup - Rapid API/SDK information lookup
challenge - Critical thinking utility

Disabled by default:

analyze, refactor, testgen, secaudit, docgen, tracer

Enabling Additional Tools

To enable additional tools, remove them from the DISABLED_TOOLS list:

Option 1: Edit your .env file

# Default configuration (from .env.example)
DISABLED_TOOLS=analyze,refactor,testgen,secaudit,docgen,tracer

# To enable specific tools, remove them from the list
# Example: Enable analyze tool
DISABLED_TOOLS=refactor,testgen,secaudit,docgen,tracer

# To enable ALL tools
DISABLED_TOOLS=

Option 2: Configure in MCP settings

// In ~/.claude/settings.json or .mcp.json
{
  "mcpServers": {
    "pal": {
      "env": {
        // Tool configuration
        "DISABLED_TOOLS": "refactor,testgen,secaudit,docgen,tracer",
        "DEFAULT_MODEL": "pro",
        "DEFAULT_THINKING_MODE_THINKDEEP": "high",
        
        // API configuration
        "GEMINI_API_KEY": "your-gemini-key",
        "OPENAI_API_KEY": "your-openai-key",
        "OPENROUTER_API_KEY": "your-openrouter-key",
        
        // Logging and performance
        "LOG_LEVEL": "INFO",
        "CONVERSATION_TIMEOUT_HOURS": "6",
        "MAX_CONVERSATION_TURNS": "50"
      }
    }
  }
}

Option 3: Enable all tools

// Remove or empty the DISABLED_TOOLS to enable everything
{
  "mcpServers": {
    "pal": {
      "env": {
        "DISABLED_TOOLS": ""
      }
    }
  }
}

Note:

Essential tools (version, listmodels) cannot be disabled
After changing tool configuration, restart your Claude session for changes to take effect
Each tool adds to context window usage, so only enable what you need

📺 Watch Tools In Action

Picking Redis vs Memcached:

Chat Redis or Memcached_web.webm

Multi-turn conversation with continuation:

Chat With Gemini_web.webm

Multi-model consensus debate:

PAL Consensus Debate

Pre-commit validation workflow:

Without PAL - outdated APIs:

API without PAL

With PAL - current APIs:

API with PAL

Without PAL:

without_pal@2x

With PAL:

with_pal@2x

Key Features

AI Orchestration

Auto model selection - Claude picks the right AI for each task
Multi-model workflows - Chain different models in single conversations
Conversation continuity - Context preserved across tools and models
Context revival - Continue conversations even after context resets

Model Support

Multiple providers - Gemini, OpenAI, Azure, X.AI, OpenRouter, DIAL, Ollama
Latest models - GPT-5, Gemini 3.0 Pro, O3, Grok-4, local Llama
Thinking modes - Control reasoning depth vs cost
Vision support - Analyze images, diagrams, screenshots

Developer Experience

Guided workflows - Systematic investigation prevents rushed analysis
Smart file handling - Auto-expand directories, manage token limits
Web search integration - Access current documentation and best practices
Large prompt support - Bypass MCP's 25K token limit

Example Workflows

Multi-model Code Review:

"Perform a codereview using gemini pro and o3, then use planner to create a fix strategy"

→ Claude reviews code systematically → Consults Gemini Pro → Gets O3's perspective → Creates unified action plan

Collaborative Debugging:

"Debug this race condition with max thinking mode, then validate the fix with precommit"

→ Deep investigation → Expert analysis → Solution implementation → Pre-commit validation

Architecture Planning:

"Plan our microservices migration, get consensus from pro and o3 on the approach"

→ Structured planning → Multiple expert opinions → Consensus building → Implementation roadmap

👉 Advanced Usage Guide for complex workflows, model configuration, and power-user features

Quick Links

📖 Documentation

Docs Overview - High-level map of major guides
Getting Started - Complete setup guide
Tools Reference - All tools with examples
Advanced Usage - Power user features
Configuration - Environment variables, restrictions
Adding Providers - Provider-specific setup (OpenAI, Azure, custom gateways)
Model Ranking Guide - How intelligence scores drive auto-mode suggestions

🔧 Setup & Support

WSL Setup - Windows users
Troubleshooting - Common issues
Contributing - Code standards, PR process

License

Apache 2.0 License - see LICENSE file for details.

Acknowledgments

Built with the power of Multi-Model AI collaboration 🤝

Star History

Available Tools

18 tools

analyzeB

Read-only

Performs comprehensive code analysis with systematic investigation and expert validation. Use for architecture, performance, maintainability, and pattern analysis. Guides through structured code review and strategic planning.

ParametersJSON Schema

Name	Required	Description	Default
`step`	Yes	The analysis plan. Step 1: State your strategy, including how you will map the codebase structure, understand business logic, and assess code quality, performance implications, and architectural patterns. Later steps: Report findings and adapt the approach as new insights emerge.
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Optional absolute paths to architecture diagrams or visual references that help with analysis context.
`findings`	Yes	Summary of discoveries from this step, including architectural patterns, tech stack assessment, scalability characteristics, performance implications, maintainability factors, and strategic improvement opportunities. IMPORTANT: Document both strengths (good patterns, solid architecture) and concerns (tech debt, overengineering, unnecessary complexity). In later steps, confirm or update past findings with additional evidence.
`confidence`	No	Your confidence in the analysis: exploring, low, medium, high, very_high, almost_certain, or certain. 'certain' indicates the analysis is complete and ready for validation.
`step_number`	Yes	The index of the current step in the analysis sequence, beginning at 1. Each step should build upon or revise the previous one.
`temperature`	No	0 = deterministic · 1 = creative.
`total_steps`	Yes	Your current estimate for how many steps will be needed to complete the analysis. Adjust as new findings emerge.
`issues_found`	No	Issues or concerns identified during analysis, each with severity level (critical, high, medium, low)
`analysis_type`	No	Type of analysis to perform (architecture, performance, security, quality, general)	general
`files_checked`	No	List all files examined (absolute paths). Include even ruled-out files to track exploration path.
`output_format`	No	How to format the output (summary, detailed, actionable)	detailed
`thinking_mode`	No	Reasoning depth: minimal, low, medium, high, or max.
`relevant_files`	No	Subset of files_checked directly relevant to analysis findings (absolute paths). Include files with significant patterns, architectural decisions, or strategic improvement opportunities.
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	Set to true if you plan to continue the investigation with another step. False means you believe the analysis is complete and ready for expert validation.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.

TDQS

B3.3/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true, and the description aligns with analysis being read-only. However, the description does not disclose the multi-step workflow (step_number, total_steps), the use of continuation_id for multi-turn conversations, or the model selection behavior, which are critical behavioral traits 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, concise and front-loaded with purpose. No unnecessary repetition, though it could benefit from slightly more detail on workflow without being verbose.

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's complexity (18 parameters, 6 required, multi-step workflow, no output schema), the description is too sparse. It omits the iterative step process, continuation_id usage, and how to interpret findings, leaving the AI agent underinformed.

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 100%, so the schema alone fully documents parameters. The description adds no additional parameter-specific meaning, meeting the baseline expectation but not exceeding it.

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 it performs comprehensive code analysis for architecture, performance, etc., and uses verb 'analyze' with specific domains. However, it does not explicitly differentiate from sibling tools like codereview or secaudit, which also analyze code.

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 says 'Use for architecture, performance, maintainability, and pattern analysis' but gives no guidance on when not to use it or alternatives. It lacks explicit when-not or comparisons to siblings.

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

apilookupA

Read-only

Use this tool automatically when you need current API/SDK documentation, latest version info, breaking changes, deprecations, migration guides, or official release notes. This tool searches authoritative sources (official docs, GitHub, package registries) to ensure up-to-date accuracy.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	The API, SDK, library, framework, or technology you need current documentation, version info, breaking changes, or migration guidance for.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, and description adds context about searching authoritative sources and ensuring up-to-date accuracy. No contradictions; adequately describes behavior for a read-only search tool.

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, no fluff. Front-loaded with usage instruction. Every sentence 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?

Given simple tool with one param and no output schema, description covers enough. Could mention what happens if search fails, but otherwise complete for the tool's purpose.

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?

Only one parameter 'prompt' with schema coverage 100%. Description adds value by listing examples of what to include (API, SDK, library, etc.), beyond the schema's generic description.

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?

Description clearly states the tool provides current API/SDK documentation, version info, breaking changes, etc. Specific verb 'search' and resource types listed. Distinct from sibling tools like analyze or chat.

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?

Explicitly says 'Use this tool automatically when you need current API/SDK documentation...' providing clear context for use. Does not mention when not to use or alternatives, but usage context is well-defined.

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

challengeA

Read-only

Prevents reflexive agreement by forcing critical thinking and reasoned analysis when a statement is challenged. Trigger automatically when a user critically questions, disagrees or appears to push back on earlier answers, and use it manually to sanity-check contentious claims.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	Statement to scrutinize. If you invoke `challenge` manually, strip the word 'challenge' and pass just the statement. Automatic invocations send the full user message as-is; do not modify it.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=true, confirming no side effects. The description adds behavioral context by specifying it forces critical thinking and is used for sanity-checking, which aligns with the read-only nature. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with core purpose, no redundancy. Every word is necessary and informative.

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 single parameter with thorough schema description, read-only annotation, and no output schema, the description covers the essential context: when and how to use. Lacks mention of output format, but that is not critical for this tool.

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 100% for the single parameter 'prompt', which already provides detailed instructions (stripping 'challenge' for manual invocations). The tool description does not add further parameter information, so baseline 3 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 clearly states the tool's purpose: to prevent reflexive agreement by forcing critical thinking and reasoned analysis when a statement is challenged. It identifies the specific action (scrutinizing statements) and distinguishes its role among siblings like 'analyze' and 'thinkdeep'.

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?

Explicitly states when to use: automatically when a user critically questions or disagrees, and manually for sanity-checking contentious claims. Does not explicitly mention when not to use or alternative siblings, but the guidance is clear and actionable.

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

chatA

General chat and collaborative thinking partner for brainstorming, development discussion, getting second opinions, and exploring ideas. Use for ideas, validations, questions, and thoughtful explanations.

ParametersJSON Schema

Name	Required	Description
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Image paths (absolute) or base64 strings for optional visual context.
`prompt`	Yes	Your question or idea for collaborative thinking to be sent to the external model. Provide detailed context, including your goal, what you've tried, and any specific challenges. WARNING: Large inline code must NOT be shared in prompt. Provide full-path to files on disk as separate parameter.
`temperature`	No	0 = deterministic · 1 = creative.
`thinking_mode`	No	Reasoning depth: minimal, low, medium, high, or max.
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`absolute_file_paths`	No	Full, absolute file paths to relevant code in order to share with external model
`working_directory_absolute_path`	Yes	Absolute path to an existing directory where generated code artifacts can be saved.

TDQS

A3.5/5.0

Behavior2/5

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

The description lacks disclosure of behavioral traits beyond the annotation 'readOnlyHint: false'. It does not specify side effects, state changes, or prerequisites for using this tool.

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 highly concise, consisting of two sentences that effectively convey the tool's purpose and typical usage without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers the purpose and typical use cases but omits details about the return format and conversation mechanics (e.g., continuation_id usage), which are only partially addressed in the schema.

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 coverage is 100%, and each parameter has a clear description. The tool description adds general context but does not significantly enhance parameter understanding beyond what the schema provides.

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 is for 'general chat and collaborative thinking' for brainstorming, discussions, and exploring ideas. It differentiates from sibling tools like 'codereview' or 'debug' by being broad and open-ended.

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 lists use cases like 'ideas, validations, questions, and thoughtful explanations' but does not explicitly state when to avoid this tool or direct users to specific siblings for specialized tasks.

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

clinkB

Link a request to an external AI CLI (Gemini CLI, Qwen CLI, etc.) through PAL MCP to reuse their capabilities inside existing workflows.

ParametersJSON Schema

Name	Required	Description
`role`	No	Optional role preset defined for the selected CLI (defaults to 'default'). Roles per CLI: claude: codereviewer, default, planner; codex: codereviewer, default, planner; gemini: codereviewer, default, planner
`model`	No	Optional CLI model name. Use native to suppress clink model injection and let the CLI default apply.
`images`	No	Optional absolute image paths or base64 blobs for visual context.
`prompt`	Yes	User request forwarded to the CLI (conversation context is pre-applied).
`cli_name`	Yes	Configured CLI client name (from conf/cli_clients). Available: claude, codex, gemini
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`absolute_file_paths`	No	Full paths to relevant code

TDQS

B3.4/5.0

Behavior2/5

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

Annotations indicate read-only is false, but the description adds little beyond that; it mentions pre-applying conversation context but omits side effects, auth needs, or rate limits.

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, well-structured sentence with no wasted words.

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?

With 7 parameters, no output schema, and complex interactions (multi-CLI, role presets), the description is too terse and fails to explain response format or error conditions.

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 100%, so the description adds minimal extra meaning; baseline score of 3 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 clearly states it links a request to an external AI CLI to reuse capabilities, distinguishing it from direct action siblings like analyze or chat.

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?

It implies usage for integrating external CLI capabilities into workflows but lacks explicit when-not-to-use or alternative tool guidance.

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

codereviewB

Read-only

Performs systematic, step-by-step code review with expert validation. Use for comprehensive analysis covering quality, security, performance, and architecture. Guides through structured investigation to ensure thoroughness.

ParametersJSON Schema

Name	Required	Description	Default
`step`	Yes	Review narrative. Step 1: outline the review strategy. Later steps: report findings. MUST cover quality, security, performance, and architecture. Reference code via `relevant_files`; avoid dumping large snippets.
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Optional diagram or screenshot paths that clarify review context.
`findings`	Yes	Capture findings (positive and negative) across quality, security, performance, and architecture; update each step.
`focus_on`	No	Optional note on areas to emphasise (e.g. 'threading', 'auth flow').
`standards`	No	Coding standards or style guides to enforce.
`confidence`	No	Confidence level: exploring (just starting), low (early investigation), medium (some evidence), high (strong evidence), very_high (comprehensive understanding), almost_certain (near complete confidence), certain (100% confidence locally - no external validation needed)
`hypothesis`	No	Current theory about issue/goal based on work
`review_type`	No	Review focus: full, security, performance, or quick.	full
`step_number`	Yes	Current review step (starts at 1) – each step should build on the last.
`temperature`	No	0 = deterministic · 1 = creative.
`total_steps`	Yes	Number of review steps planned. External validation: two steps (analysis + summary). Internal validation: one step. Use the same limits when continuing an existing review via continuation_id.
`issues_found`	No	Issues with severity (critical/high/medium/low) and descriptions.
`files_checked`	No	Absolute paths of every file reviewed, including those ruled out.
`thinking_mode`	No	Reasoning depth: minimal, low, medium, high, or max.
`relevant_files`	No	Step 1: list all files/dirs under review. Must be absolute full non-abbreviated paths. Final step: narrow to files tied to key findings.
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`severity_filter`	No	Lowest severity to include when reporting issues (critical/high/medium/low/all).	all
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	True when another review step follows. External validation: step 1 → True, step 2 → False. Internal validation: set False immediately. Apply the same rule on continuation flows.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.
`review_validation_type`	No	Set 'external' (default) for expert follow-up or 'internal' for local-only review.	external

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds 'step-by-step' and 'expert validation' but does not disclose other behavioral traits (e.g., auth needs, side effects, or what happens during the review process). The annotation covers the key safety aspect.

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 concise at two sentences, front-loading the purpose. It avoids redundancy, but could be slightly more structured by mentioning the step process earlier.

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?

With 22 parameters and no output schema, the description should provide more context on how to use the multi-step review process (e.g., step lifecycle, continuation_id usage). It lacks sufficient guidance for such a complex tool.

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 100%, meaning all 22 parameters have individual descriptions in the schema. The description adds no additional parameter-level information. Baseline 3 is appropriate as the schema does the heavy lifting.

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 it performs systematic, step-by-step code review covering quality, security, performance, and architecture. It distinguishes itself from siblings like 'secaudit' or 'debug' by emphasizing a structured process and expert validation, but does not explicitly differentiate from all siblings.

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 says 'Use for comprehensive analysis' but provides no explicit guidance on when to use this tool versus alternatives (e.g., secaudit for security, debug for debugging). No when-not-to-use or conditions are mentioned.

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

consensusA

Read-only

Builds multi-model consensus through systematic analysis and structured debate. Use for complex decisions, architectural choices, feature proposals, and technology evaluations. Consults multiple models with different stances to synthesize comprehensive recommendations.

ParametersJSON Schema

Name	Required	Description
`step`	Yes	Consensus prompt. Step 1: write the exact proposal/question every model will see (use 'Evaluate…', not meta commentary). Steps 2+: capture internal notes about the latest model response—these notes are NOT sent to other models.
`images`	No	Optional absolute image paths or base64 references that add helpful visual context.
`models`	No	User-specified roster of models to consult (provide at least two entries). User-specified list of models to consult (provide at least two entries). Each entry may include model, stance (for/against/neutral), and stance_prompt. Each (model, stance) pair must be unique, e.g. [{'model':'gpt5','stance':'for'}, {'model':'pro','stance':'against'}]. When the user names a model, you MUST use that exact value or report the provider error—never swap in another option. Use the `listmodels` tool for the full roster. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`findings`	Yes	Step 1: your independent analysis for later synthesis (not shared with other models). Steps 2+: summarize the newest model response.
`step_number`	Yes	Current step index (starts at 1). Step 1 is your analysis; steps 2+ handle each model response.
`total_steps`	Yes	Total steps = number of models consulted plus the final synthesis step.
`relevant_files`	No	Optional supporting files that help the consensus analysis. Must be absolute full, non-abbreviated paths.
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`model_responses`	No	Internal log of responses gathered so far.
`next_step_required`	Yes	True if more model consultations remain; set false when ready to synthesize.
`current_model_index`	No	0-based index of the next model to consult (managed internally).
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, indicating no state modification. The description adds that the tool consults multiple models, which implies external calls but does not detail potential costs, rate limits, or other side effects. There is 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences front-loaded with the core action. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the multi-step consensus process and lack of an output schema, the description gives a general idea but omits procedural details and return value format. It does not fully prepare users for the step-based workflow evident in the input schema.

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?

With 100% schema description coverage, the input schema already thoroughly explains each parameter. The tool description provides a high-level overview but does not add significant new semantic information 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 clearly states the tool's purpose: building multi-model consensus through analysis and debate. It lists specific use cases like complex decisions, architectural choices, feature proposals, and technology evaluations, effectively distinguishing it from sibling 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?

The description provides clear guidance on when to use the tool for complex decisions and evaluations. However, it does not explicitly mention when not to use it or direct users to alternative tools, though the context is sufficient for appropriate use.

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

debugA

Read-only

Performs systematic debugging and root cause analysis for any type of issue. Use for complex bugs, mysterious errors, performance issues, race conditions, memory leaks, and integration problems. Guides through structured investigation with hypothesis testing and expert analysis.

ParametersJSON Schema

Name	Required	Description
`step`	Yes	Investigation step. Step 1: State issue+direction. Symptoms misleading; 'no bug' valid. Trace dependencies, verify hypotheses. Use relevant_files for code; this for text only.
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Optional screenshots/visuals clarifying issue (absolute paths).
`findings`	Yes	Discoveries: clues, code/log evidence, disproven theories. Be specific. If no bug found, document clearly as valid.
`confidence`	No	Your confidence in the hypothesis: exploring (starting out), low (early idea), medium (some evidence), high (strong evidence), very_high (very strong evidence), almost_certain (nearly confirmed), certain (100% confidence - root cause and fix are both confirmed locally with no need for external validation). WARNING: Do NOT use 'certain' unless the issue can be fully resolved with a fix, use 'very_high' or 'almost_certain' instead when not 100% sure. Using 'certain' means you have ABSOLUTE confidence locally and PREVENTS external model validation.
`hypothesis`	No	Concrete root cause theory from evidence. Can revise. Valid: 'No bug found - user misunderstanding' or 'Symptoms unrelated to code' if supported.
`step_number`	Yes	Current step index (starts at 1). Build upon previous steps.
`temperature`	No	0 = deterministic · 1 = creative.
`total_steps`	Yes	Estimated total steps needed to complete the investigation. Adjust as new findings emerge. IMPORTANT: When continuation_id is provided (continuing a previous conversation), set this to 1 as we're not starting a new multi-step investigation.
`issues_found`	No	Issues identified with severity levels during work
`files_checked`	No	All examined files (absolute paths), including ruled-out ones.
`thinking_mode`	No	Reasoning depth: minimal, low, medium, high, or max.
`relevant_files`	No	Files directly relevant to issue (absolute paths). Cause, trigger, or manifestation locations.
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	True if you plan to continue the investigation with another step. False means root cause is known or investigation is complete. IMPORTANT: When continuation_id is provided (continuing a previous conversation), set this to False to immediately proceed with expert analysis.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.

TDQS

A4.1/5.0

Behavior5/5

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

The description extensively discloses behavioral traits beyond annotations: it outlines a structured investigation process, explains parameter importance (e.g., confidence levels with warnings), and notes the continuation_id for multi-turn conversations. No contradiction with readOnlyHint.

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, front-loaded with purpose and usage guidance. Every sentence adds value without redundancy, achieving high conciseness.

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 (17 parameters, no output schema), the description plus schema provide sufficient context for investigation. It lacks explicit detail on return format or post-analysis steps, but the workflow is adequately conveyed.

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 input schema provides 100% documentation coverage for all 17 parameters with detailed descriptions. The tool's free-form description adds no extra parameter info beyond what the schema gives, so baseline 3 is appropriate.

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 the tool performs systematic debugging and root cause analysis for various issues (complex bugs, errors, performance issues, etc.). It uses a specific verb-phrase and lists example use cases, but does not explicitly differentiate from sibling tools like 'analyze' or 'codereview'.

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 explicit guidance on when to use the tool: 'Use for complex bugs, mysterious errors, performance issues, race conditions, memory leaks, and integration problems.' This sets clear context, though it omits when not to use or alternative tools.

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

docgenA

Read-only

Generates comprehensive code documentation with systematic analysis of functions, classes, and complexity. Use for documentation generation, code analysis, complexity assessment, and API documentation. Analyzes code structure and patterns to create thorough documentation.

ParametersJSON Schema

Name	Required	Description
`step`	Yes	Current work step content and findings from your overall work
`findings`	Yes	Important findings, evidence and insights discovered in this step
`step_number`	Yes	Current step number in work sequence (starts at 1)
`total_steps`	Yes	Estimated total steps needed to complete work
`issues_found`	No	Issues identified with severity levels during work
`document_flow`	Yes	Include call flow/dependency notes when True (default).
`relevant_files`	No	Files identified as relevant to issue/goal (FULL absolute paths to real files/folders - DO NOT SHORTEN)
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`update_existing`	Yes	True (default) to polish inaccurate or outdated docs instead of leaving them untouched.
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	Whether another work step is needed. When false, aim to reduce total_steps to match step_number to avoid mismatch.
`document_complexity`	Yes	Include algorithmic complexity (Big O) analysis when True (default).
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.
`num_files_documented`	Yes	Count of files finished so far. Increment only when a file is fully documented.
`total_files_to_document`	Yes	Total files identified in discovery; completion requires matching this count.
`comments_on_complex_logic`	Yes	True (default) to add inline comments around non-obvious logic.

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true; description adds 'generates' which is consistent but does not disclose further behavioral details such as auth requirements or limitations.

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 concise sentences that front-load the purpose and use cases; no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high parameter count and no output schema, the description is sufficient for a high-level understanding but lacks details on workflow or step-by-step usage.

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 coverage is 100%, so description does not need to add parameter details; it provides no additional meaning 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 clearly states the tool generates code documentation with systematic analysis of functions, classes, and complexity, distinguishing it from siblings like codereview and testgen.

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 lists explicit use cases (documentation generation, code analysis, complexity assessment, API documentation) but does not provide when-not-to-use or compare directly to alternatives.

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

listmodelsA

Read-only

Shows which AI model providers are configured, available model names, their aliases and capabilities.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds useful context about what information is returned (providers, names, aliases, capabilities), but it does not disclose additional behavioral traits such as pagination or formatting.

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, concise sentence that front-loads the verb 'Shows' and packs all relevant information about the tool's output without unnecessary words.

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 no parameters and no output schema, but the description sufficiently covers its purpose and the categories of data it returns. It could be slightly more complete by mentioning that no arguments are required, but that is implicit in the empty input schema.

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, so there is nothing for the description to elaborate. The baseline score of 4 applies, as no parameter information is needed.

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 'Shows' and clearly defines the resource: configured AI model providers, available model names, aliases, and capabilities. This clearly distinguishes it from sibling tools like chat and dump_threads.

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 usage—you'd use this tool when you need to see configured models—but it does not provide explicit guidance on when to use it versus alternatives like chat or dump_threads. There is no direct comparison or exclusion.

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

plannerA

Read-only

Breaks down complex tasks through interactive, sequential planning with revision and branching capabilities. Use for complex project planning, system design, migration strategies, and architectural decisions. Builds plans incrementally with deep reflection for complex scenarios.

ParametersJSON Schema

Name	Required	Description
`step`	Yes	Planning content for this step. Step 1: describe the task, problem and scope. Later steps: capture updates, revisions, branches, or open questions that shape the plan.
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`branch_id`	No	Name for this branch (e.g. 'approach-A', 'migration-path').
`step_number`	Yes	Current step number in work sequence (starts at 1)
`total_steps`	Yes	Estimated total steps needed to complete work
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`is_branch_point`	No	True when this step creates a new branch to explore an alternative path.
`branch_from_step`	No	If branching, the step number that this branch starts from.
`is_step_revision`	No	Set true when you are replacing a previously recorded step.
`more_steps_needed`	No	True when you now expect to add additional steps beyond the prior estimate.
`next_step_required`	Yes	Whether another work step is needed. When false, aim to reduce total_steps to match step_number to avoid mismatch.
`revises_step_number`	No	Step number being replaced when revising.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.

TDQS

A3.5/5.0

Behavior2/5

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

Description says 'builds plans' implying modification, but annotation readOnlyHint=true suggests no side effects. This contradiction reduces transparency. Lacks details on plan storage, duration, or output format.

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?

Two sentences, front-loaded with purpose and capabilities. Efficient but could be structured with bullet points for clarity.

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?

With 13 parameters and no output schema, the description lacks sufficient guidance on how to use the tool effectively, such as step flow or interaction model.

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 covers 100% of parameters with descriptions, so baseline is 3. Tool description briefly mentions revision and branching, but does not add significant meaning 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?

Tool name 'planner' and description clearly state it breaks down complex tasks for planning, system design, etc., distinguishing it from sibling tools like analyze, chat, or testgen.

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?

Explicitly recommends use for complex project planning, system design, migration strategies, and architectural decisions. Does not explicitly state when to avoid or name alternatives, but context signals and sibling list imply other tools for simpler tasks.

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

precommitA

Read-only

Validates git changes and repository state before committing with systematic analysis. Use for multi-repository validation, security review, change impact assessment, and completeness verification. Guides through structured investigation with expert analysis.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Absolute path to the repository root. Required in step 1.
`step`	Yes	Step 1: outline how you'll validate the git changes. Later steps: report findings. Review diffs and impacts, use `relevant_files`, and avoid pasting large snippets.
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Optional absolute paths to screenshots or diagrams that aid validation.
`findings`	Yes	Record git diff insights, risks, missing tests, security concerns, and positives; update previous notes as you go.
`focus_on`	No	Optional emphasis areas such as security, performance, or test coverage.
`compare_to`	No	Optional git ref (branch/tag/commit) to diff against; falls back to staged/unstaged changes.
`confidence`	No	Confidence level: exploring (just starting), low (early investigation), medium (some evidence), high (strong evidence), very_high (comprehensive understanding), almost_certain (near complete confidence), certain (100% confidence locally - no external validation needed)
`hypothesis`	No	Current theory about issue/goal based on work
`step_number`	Yes	Current pre-commit step number (starts at 1).
`temperature`	No	0 = deterministic · 1 = creative.
`total_steps`	Yes	Planned number of validation steps. External validation: use at most three (analysis → follow-ups → summary). Internal validation: a single step. Honour these limits when resuming via continuation_id.
`issues_found`	No	List issues with severity (critical/high/medium/low) plus descriptions (bugs, security, performance, coverage).
`files_checked`	No	Absolute paths for every file examined, including ruled-out candidates.
`thinking_mode`	No	Reasoning depth: minimal, low, medium, high, or max.
`include_staged`	No	Whether to inspect staged changes (ignored when `compare_to` is set).
`precommit_type`	No	'external' (default, triggers expert model) or 'internal' (local-only validation).	external
`relevant_files`	No	Absolute paths of files involved in the change or validation (code, configs, tests, docs). Must be absolute full non-abbreviated paths.
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`severity_filter`	No	Lowest severity to include when reporting issues.	all
`include_unstaged`	No	Whether to inspect unstaged changes (ignored when `compare_to` is set).
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	True to continue with another step, False when validation is complete. CRITICAL: If total_steps>=3 or when `precommit_type = external`, set to True until the final step. When continuation_id is provided: Follow the same validation rules based on precommit_type.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.

TDQS

A3.7/5.0

Behavior4/5

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

The description consistently aligns with the readOnlyHint annotation, emphasizing validation and analysis. It adds value by explaining the structured multi-step process, use of expert models, and distinction between external and internal validation. No contradictions 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of three succinct sentences, immediately stating the core purpose, use cases, and guidance. No unnecessary wording; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (24 parameters, no output schema), the description provides only high-level context. It omits details on the multi-step validation process and parameter interdependencies, which are partially covered in the schema but could benefit from description-level hints.

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 100%, so baseline 3 is appropriate. The description does not elaborate on parameter usage beyond what the schema provides, but the tool's high-level purpose and workflow context are clear.

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 the tool validates git changes before committing, with specific use cases for multi-repository validation, security review, and change impact assessment. It differentiates from siblings like codereview or secaudit by being a systematic validation, but does not explicitly exclude them.

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 lists use cases ('multi-repository validation, security review, change impact assessment, and completeness verification') but fails to provide guidance on when not to use this tool or suggest alternative sibling tools for narrower tasks like pure security audits.

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

refactorA

Read-only

Analyzes code for refactoring opportunities with systematic investigation. Use for code smell detection, decomposition planning, modernization, and maintainability improvements. Guides through structured analysis with expert validation.

ParametersJSON Schema

Name	Required	Description	Default
`step`	Yes	The refactoring plan. Step 1: State strategy. Later steps: Report findings. CRITICAL: Examine code for smells, and opportunities for decomposition, modernization, and organization. Use 'relevant_files' for code. FORBIDDEN: Large code snippets.
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Optional list of absolute paths to architecture diagrams, UI mockups, design documents, or visual references that help with refactoring context. Only include if they materially assist understanding or assessment.
`findings`	Yes	Summary of discoveries from this step, including code smells and opportunities for decomposition, modernization, or organization. Document both strengths and weaknesses. In later steps, confirm or update past findings.
`confidence`	No	Your confidence in refactoring analysis: exploring (starting), incomplete (significant work remaining), partial (some opportunities found, more analysis needed), complete (comprehensive analysis finished, all major opportunities identified). WARNING: Use 'complete' ONLY when fully analyzed and can provide recommendations without expert help. 'complete' PREVENTS expert validation. Use 'partial' for large files or uncertain analysis.	incomplete
`hypothesis`	No	Current theory about issue/goal based on work
`focus_areas`	No	Specific areas to focus on (e.g., 'performance', 'readability', 'maintainability', 'security')
`step_number`	Yes	The index of the current step in the refactoring investigation sequence, beginning at 1. Each step should build upon or revise the previous one.
`temperature`	No	0 = deterministic · 1 = creative.
`total_steps`	Yes	Your current estimate for how many steps will be needed to complete the refactoring investigation. Adjust as new opportunities emerge.
`issues_found`	No	Refactoring opportunities as dictionaries with 'severity' (critical/high/medium/low), 'type' (codesmells/decompose/modernize/organization), and 'description'. Include all improvement opportunities found.
`files_checked`	No	List all files examined (absolute paths). Include even ruled-out files to track exploration path.
`refactor_type`	No	Type of refactoring analysis to perform (codesmells, decompose, modernize, organization)	codesmells
`thinking_mode`	No	Reasoning depth: minimal, low, medium, high, or max.
`relevant_files`	No	Subset of files_checked with code requiring refactoring (absolute paths). Include files with code smells, decomposition needs, or improvement opportunities.
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	Set to true if you plan to continue the investigation with another step. False means you believe the refactoring analysis is complete and ready for expert validation.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.
`style_guide_examples`	No	Optional existing code files to use as style/pattern reference (must be FULL absolute paths to real files / folders - DO NOT SHORTEN). These files represent the target coding style and patterns for the project.

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description aligns with that. The description adds context about 'structured analysis with expert validation', hinting at a multi-step process, but does not fully disclose the iterative step-based workflow implied by the schema (step_number, total_steps, next_step_required).

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 just three sentences, front-loaded with the core purpose. It is concise and free of redundancy, though it could be slightly more structured to outline the multi-step process.

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's complexity (20 parameters, 6 required, multi-step protocol), the description is too brief. It does not explain the iterative step nature, how to use step_number/total_steps, or the role of expert validation, leaving significant gaps for an AI agent to infer from the schema alone.

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 100%, so the schema already documents all 20 parameters thoroughly. Baseline is 3, and the tool description does not add additional parameter meaning beyond what the schema provides.

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: 'Analyzes code for refactoring opportunities with systematic investigation' and lists specific use cases (code smell detection, decomposition planning, modernization, maintainability improvements). It differentiates from siblings like 'codereview' and 'analyze' by emphasizing systematic investigation and expert validation.

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 'Use for code smell detection, decomposition planning, modernization, and maintainability improvements', providing clear usage context. However, it lacks explicit guidance on when not to use or mention of alternatives among siblings.

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

secauditA

Read-only

Performs comprehensive security audit with systematic vulnerability assessment. Use for OWASP Top 10 analysis, compliance evaluation, threat modeling, and security architecture review. Guides through structured security investigation with expert validation.

ParametersJSON Schema

Name	Required	Description	Default
`step`	Yes	Step 1: outline the audit strategy (OWASP Top 10, auth, validation, etc.). Later steps: report findings. MANDATORY: use `relevant_files` for code references and avoid large snippets.
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Optional absolute paths to diagrams or threat models that inform the audit.
`findings`	Yes	Summarize vulnerabilities, auth issues, validation gaps, compliance notes, and positives; update prior findings as needed.
`confidence`	No	exploring/low/medium/high/very_high/almost_certain/certain. 'certain' blocks external validation—use only when fully complete.
`hypothesis`	No	Current theory about issue/goal based on work
`audit_focus`	No	Primary focus area: owasp, compliance, infrastructure, dependencies, or comprehensive.	comprehensive
`step_number`	Yes	Current security-audit step number (starts at 1).
`temperature`	No	0 = deterministic · 1 = creative.
`total_steps`	Yes	Expected number of audit steps; adjust as new risks surface.
`issues_found`	No	Security issues with severity (critical/high/medium/low) and descriptions (vulns, auth flaws, injection, crypto, config).
`threat_level`	No	Assess the threat level: low (internal/low-risk), medium (customer-facing/business data), high (regulated or sensitive), critical (financial/healthcare/PII).	medium
`files_checked`	No	Absolute paths for every file inspected, including rejected candidates.
`thinking_mode`	No	Reasoning depth: minimal, low, medium, high, or max.
`relevant_files`	No	Absolute paths for security-relevant files (auth modules, configs, sensitive code).
`security_scope`	No	Security context (web, mobile, API, cloud, etc.) including stack, user types, data sensitivity, and threat landscape.
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`severity_filter`	No	Minimum severity to include when reporting security issues.	all
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	True while additional threat analysis remains; set False once you are ready to hand off for validation.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.
`compliance_requirements`	No	Applicable compliance frameworks or standards (SOC2, PCI DSS, HIPAA, GDPR, ISO 27001, NIST, etc.).

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true. Description adds value by explaining the tool's systematic approach, expert validation, and structured investigation process, which aligns with read-only analysis without contradicting annotations.

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?

Three sentences front-loaded with primary purpose and use cases. No extraneous information; each sentence adds value. Could be slightly more concise but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 22 parameters and lack of output schema, the description covers the high-level purpose but does not explain the multi-step process or how continuation_id works, which is partially covered in schema. Adequate but not comprehensive.

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 100%, so baseline is 3. The description does not add parameter-specific details beyond what is already in the schema, which is adequate for a read-heavy tool.

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?

Description clearly states it performs comprehensive security audit with systematic vulnerability assessment, and lists specific use cases (OWASP Top 10, compliance, threat modeling). It distinguishes well from sibling tools like analyze or codereview by focusing solely on security audit tasks.

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?

Explicitly states when to use: for OWASP Top 10 analysis, compliance evaluation, threat modeling, and security architecture review. Provides context for structured security investigation, but does not mention when not to use or name alternatives like analyze or codereview.

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

testgenB

Read-only

Creates comprehensive test suites with edge case coverage for specific functions, classes, or modules. Analyzes code paths, identifies failure modes, and generates framework-specific tests. Be specific about scope - target particular components rather than testing everything.

ParametersJSON Schema

Name	Required	Description
`step`	Yes	Test plan for this step. Step 1: outline how you'll analyse structure, business logic, critical paths, and edge cases. Later steps: record findings and new scenarios as they emerge.
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Optional absolute paths to diagrams or visuals that clarify the system under test.
`findings`	Yes	Summarise functionality, critical paths, edge cases, boundary conditions, error handling, and existing test patterns. Cover both happy and failure paths.
`confidence`	No	Indicate your current confidence in the test generation assessment. Use: 'exploring' (starting analysis), 'low' (early investigation), 'medium' (some patterns identified), 'high' (strong understanding), 'very_high' (very strong understanding), 'almost_certain' (nearly complete test plan), 'certain' (100% confidence - test plan is thoroughly complete and all test scenarios are identified with no need for external model validation). Do NOT use 'certain' unless the test generation analysis is comprehensively complete, use 'very_high' or 'almost_certain' instead if not 100% sure. Using 'certain' means you have complete confidence locally and prevents external model validation.
`hypothesis`	No	Current theory about issue/goal based on work
`step_number`	Yes	Current test-generation step (starts at 1) — each step should build on prior work.
`temperature`	No	0 = deterministic · 1 = creative.
`total_steps`	Yes	Estimated number of steps needed for test planning; adjust as new scenarios appear.
`issues_found`	No	Issues identified with severity levels during work
`files_checked`	No	Absolute paths of every file examined, including those ruled out.
`thinking_mode`	No	Reasoning depth: minimal, low, medium, high, or max.
`relevant_files`	No	Absolute paths of code that requires new or updated tests (implementation, dependencies, existing test fixtures).
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	True while more investigation or planning remains; set False when test planning is ready for expert validation.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.

TDQS

B3.1/5.0

Behavior1/5

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

Description claims the tool 'creates' test suites, implying write operations, while annotations set readOnlyHint=true. This contradiction severely misleads agents about behavior. Score 1 per rubric.

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?

Three sentences that are direct and front-loaded. Could be slightly more structured (e.g., bullet points) but contains no filler.

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?

With 17 parameters and no output schema, the description is too brief. It does not explain the step-based workflow or how parameters like step_number, findings, or next_step_required fit into the process.

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 coverage is 100%, so baseline 3 applies. Description adds general context about test generation but does not elaborate on individual parameters beyond what schema provides.

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?

Clearly states it creates comprehensive test suites with edge case coverage for specific functions/classes/modules. Distinguishes from sibling tools like codereview or debug by focusing on test generation.

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?

Advises to be specific about scope and target particular components, but does not explicitly compare with alternatives like docgen or refactor. Lacks when-not or alternative tool guidance.

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

thinkdeepA

Read-only

Performs multi-stage investigation and reasoning for complex problem analysis. Use for architecture decisions, complex bugs, performance challenges, and security analysis. Provides systematic hypothesis testing, evidence-based investigation, and expert validation.

ParametersJSON Schema

Name	Required	Description
`step`	Yes	Current work step content and findings from your overall work
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Optional absolute image paths or base64 blobs for visual context.
`findings`	Yes	Important findings, evidence and insights discovered in this step
`confidence`	No	Confidence level: exploring (just starting), low (early investigation), medium (some evidence), high (strong evidence), very_high (comprehensive understanding), almost_certain (near complete confidence), certain (100% confidence locally - no external validation needed)
`hypothesis`	No	Current theory about issue/goal based on work
`focus_areas`	No	Focus aspects (architecture, performance, security, etc.)
`step_number`	Yes	Current step number in work sequence (starts at 1)
`temperature`	No	0 = deterministic · 1 = creative.
`total_steps`	Yes	Estimated total steps needed to complete work
`issues_found`	No	Issues identified with severity levels during work
`files_checked`	No	List of files examined during this work step
`thinking_mode`	No	Reasoning depth: minimal, low, medium, high, or max.
`relevant_files`	No	Files identified as relevant to issue/goal (FULL absolute paths to real files/folders - DO NOT SHORTEN)
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`problem_context`	No	Additional context about problem/goal. Be expressive.
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	Whether another work step is needed. When false, aim to reduce total_steps to match step_number to avoid mismatch.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, and the description reinforces this by describing analysis activities (investigation, reasoning, hypothesis testing) without any implication of state modification. The description adds behavioral context about multi-stage processing and expert validation that annotations alone do not provide.

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 no fluff: first states purpose, second lists use cases, third summarizes capabilities. Every sentence adds value. The description is front-loaded with the most critical information.

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?

Despite having 19 parameters and no output schema, the description provides adequate high-level context about the tool's multi-stage nature and systematic approach. The schema fields (step, step_number, findings, etc.) further clarify the workflow. Missing details about output format are compensated by the schema's explicitness.

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 100%, so the schema already documents all parameter meanings comprehensively. The description does not add parameter-level details beyond the schema, but that is acceptable since the schema descriptions are thorough. Baseline 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 clearly states the tool's specific verb-resource combination: 'Performs multi-stage investigation and reasoning' for complex problem analysis. It lists concrete use cases (architecture decisions, complex bugs, performance challenges, security analysis), effectively distinguishing it from sibling tools like analyze, debug, or secaudit which are more focused or single-stage.

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, actionable guidance on when to use this tool by listing appropriate scenarios. However, it does not explicitly state when not to use it (e.g., simple lookups) or compare to similar siblings. Despite this, the context is sufficiently clear for an AI agent to make appropriate selection.

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

tracerA

Read-only

Performs systematic code tracing with modes for execution flow or dependency mapping. Use for method execution analysis, call chain tracing, dependency mapping, and architectural understanding. Supports precision mode (execution flow) and dependencies mode (structural relationships).

ParametersJSON Schema

Name	Required	Description
`step`	Yes	Current work step content and findings from your overall work
`model`	Yes	Currently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
`images`	No	Optional paths to architecture diagrams or flow charts that help understand the tracing context.
`findings`	Yes	Important findings, evidence and insights discovered in this step
`confidence`	No	Confidence level: exploring (just starting), low (early investigation), medium (some evidence), high (strong evidence), very_high (comprehensive understanding), almost_certain (near complete confidence), certain (100% confidence locally - no external validation needed)
`trace_mode`	Yes	Type of tracing: 'ask' (default - prompts user to choose mode), 'precision' (execution flow) or 'dependencies' (structural relationships)
`step_number`	Yes	Current step number in work sequence (starts at 1)
`total_steps`	Yes	Estimated total steps needed to complete work
`files_checked`	No	List of files examined during this work step
`relevant_files`	No	Files identified as relevant to issue/goal (FULL absolute paths to real files/folders - DO NOT SHORTEN)
`continuation_id`	No	Unique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
`relevant_context`	No	Methods/functions identified as involved in the issue
`next_step_required`	Yes	Whether another work step is needed. When false, aim to reduce total_steps to match step_number to avoid mismatch.
`target_description`	Yes	Description of what to trace and WHY. Include context about what you're trying to understand or analyze.
`use_assistant_model`	No	Use assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, confirming no destructive side effects. The description adds behavioral context by detailing the two trace modes ('precision' and 'dependencies'), which is beyond what annotations convey. There is no contradiction.

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: first defines the core action, second lists use cases, third specifies modes. Every sentence adds value, and the most important information is front-loaded.

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?

Despite the tool having 15 parameters (8 required) and no output schema, the description remains very brief. It does not provide a narrative on how to use the tool effectively, nor explain the relationship between parameters or the expected workflow, leaving the agent to rely entirely on the schema.

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 100%, so the baseline is 3. The description does not elaborate on any parameters beyond what the schema already provides, but this is acceptable given the high coverage.

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 the tool performs 'systematic code tracing' and specifies two modes: execution flow and dependency mapping. It lists use cases like method execution analysis and call chain tracing, but does not differentiate from sibling tools like 'analyze' or 'debug', which could overlap in function.

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 provides explicit use cases such as 'method execution analysis, call chain tracing, dependency mapping', but does not offer when-not-to-use guidance or compare against alternative sibling tools. The usage context is implied rather than explicit.

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

versionA

Read-only

Get server version, configuration details, and list of available tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already mark it as readOnlyHint=true. The description adds specific behaviors: retrieving version, config, and tool list. No contradictions and adds 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, direct, no filler. Every word adds value.

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 zero parameters and no output schema, the description fully explains what the tool returns (version, config, tool list). No missing context.

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 has zero parameters, so baseline is 4. The description does not need to explain parameters and focuses on the output, 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 explicitly states the tool retrieves server version, configuration details, and list of available tools. It clearly distinguishes from sibling tools like 'listmodels' (which likely lists models) and other operational tools.

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 usage for obtaining server metadata but does not provide explicit when-to-use or when-not-to-use guidance. Alternatives are not mentioned.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

18 tool updatesv9.10.0Jul 16, 2026
- First observedanalyze
- First observedapilookup
- First observedchallenge
- First observedchat
- First observedclink
- First observedcodereview
- First observedconsensus
- First observeddebug
- First observeddocgen
- First observedlistmodels
- First observedplanner
- First observedprecommit
- First observedrefactor
- First observedsecaudit
- First observedtestgen
- First observedthinkdeep
- First observedtracer
- First observedversion

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-07-16 15:11 across 18 tools

Disambiguation3/5

Many tools have overlapping purposes, particularly among analyze, codereview, debug, thinkdeep, and tracer, which all involve systematic analysis of code. Although each targets a specific aspect (architecture, security, debugging), the boundaries are fuzzy, and agents may struggle to select the appropriate tool for a given task.

Naming Consistency4/5

Tool names are uniformly lowercase concatenated words (e.g., apilookup, codereview, testgen). While some names are generic (chat, clink), there is a consistent pattern overall. However, the lack of a standard verb_noun prefix (like list_, create_) limits predictability.

Tool Count4/5

With 18 tools, the server is at the upper end of a reasonable scope. All tools seem to serve a distinct purpose, though the overlap among analysis tools suggests some consolidation could be beneficial. The count is appropriate for a comprehensive development assistant.

Completeness4/5

The tool set covers a wide range of development tasks: analysis, review, debugging, security, documentation, testing, planning, and consensus. However, it lacks tools for executing code, searching code, or direct editing, which are common in such assistants. These gaps are minor given the existing coverage.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Apuchat A
io.github.opcastil11
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Communication Agent Orchestration
181
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

MCP Server Demo
RAG Systems Agent Orchestration Autonomous Agents
tian1ll1
F
license
Not graded
quality
D
maintenance
A demonstration implementation of the Model Context Protocol server that facilitates communication between AI models and external tools while maintaining context awareness.
Updated a year ago (2025-03-24 01:04 UTC)
-
MCP Boilerplate
RAG Systems Agent Orchestration Developer Tools
iamsrikanthnani
A
license
Not graded
quality
D
maintenance
A server that implements the Model Context Protocol, providing a standardized way to connect AI models to different data sources and tools.
Updated a year ago (2025-05-12 06:05 UTC)
6 npm
11
MIT
Claude IPC MCP
Autonomous Agents Communication Developer Tools
jdez427
A
license
B
quality
C
maintenance
A Model Context Protocol server that enables AI assistants to communicate with each other using Inter-Process Communication, featuring natural language commands and cross-platform compatibility.
Updated a year ago (2025-09-25 16:37 UTC)
9
133
MIT
Agent Orchestration
Agent Orchestration Autonomous Agents
madebyaris
A
license
Not graded
quality
F
maintenance
A Model Context Protocol (MCP) server that enables multiple AI agents to share memory, coordinate tasks, and collaborate effectively across IDEs and CLI tools.
Updated 5 months ago (2026-04-05 06:17 UTC)
16 npm
17
MIT

PAL MCP: Many Workflows. One Context.

Your CLI + Multiple Models = Your AI Dev Team

🆕 Now with CLI-to-CLI Bridge

Why PAL MCP?

True AI Collaboration with Conversation Continuity

Example: Multi-Model Code Review Workflow

You are the AI - Actually Intelligent.

Recommended AI Stack

Quick Start (5 minutes)

Provider Configuration

Core Tools

Default Configuration

Enabling Additional Tools

📺 Watch Tools In Action

Key Features

Example Workflows

Quick Links

License

Acknowledgments

Star History

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers