Provides tools to interact with GitHub Copilot CLI, enabling code analysis, batch processing, code review, and brainstorming through MCP clients.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@copilot-mcp-server explain the code in @src/index.ts for me"
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.
Copilot MCP Tool is an open‑source Model Context Protocol (MCP) server that connects your IDE or AI assistant (Claude, Cursor, etc.) to GitHub Copilot CLI. It enables non‑interactive automation, safe tool execution with permissions, and large‑scale code analysis via @ file references. Built for reliability and speed, it streams progress updates, and integrates cleanly with standard MCP clients for code review, refactoring, documentation, and CI automation.
Primary: Ask GitHub Copilot CLI questions from your MCP client, with comprehensive tool management
Advanced: Batch processing, code review, and brainstorming capabilities
Goal: Use GitHub Copilot CLI directly from your MCP-enabled editor to analyze and edit code efficiently.
Related MCP server: GitHub Copilot MCP Server
Before using this tool, ensure you have:
Node.js (v18.0.0 or higher)
GitHub Copilot CLI - Required
claude mcp add copilot-cli -- npx -y @trishchuk/copilot-mcp-serverType /mcp inside Claude Code to verify the Copilot MCP is active.
If you already have it configured in Claude Desktop:
Add to your Claude Desktop config:
"copilot-cli": {
"command": "npx",
"args": ["-y", "@trishchuk/copilot-mcp-server"]
}Import to Claude Code:
claude mcp add-from-claude-desktopRegister the MCP server with your MCP client:
Add this configuration to your Claude Desktop config file:
{
"mcpServers": {
"copilot-cli": {
"command": "npx",
"args": ["-y", "@trishchuk/copilot-mcp-server"],
"env": {
"COPILOT_MODEL": "claude-sonnet-4.5"
}
}
}
}If you installed globally, use this configuration instead:
{
"mcpServers": {
"copilot-cli": {
"command": "copilot-mcp",
"env": {
"COPILOT_MODEL": "claude-sonnet-4.5"
}
}
}
}Configuration File Locations:
Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json
After updating the configuration, restart your terminal session.
Configure default behavior with environment variables:
COPILOT_MODEL - Default AI ModelMethod 1: In MCP Configuration (Recommended)
Add the env field to your MCP server configuration:
{
"mcpServers": {
"copilot-cli": {
"command": "npx",
"args": ["-y", "@trishchuk/copilot-mcp-server"],
"env": {
"COPILOT_MODEL": "claude-sonnet-4.5"
}
}
}
}Method 2: System Environment Variable
# Set for current session
export COPILOT_MODEL=claude-sonnet-4.5
# Permanently (add to ~/.bashrc or ~/.zshrc)
echo 'export COPILOT_MODEL=claude-sonnet-4.5' >> ~/.zshrcAvailable models:
claude-sonnet-4.5 - Default, best for code generation
claude-sonnet-4 - Faster version
gpt-5 - OpenAI GPT-5
Priority: model parameter > COPILOT_MODEL env > Copilot CLI default (claude-sonnet-4.5)
Override in requests:
# Uses COPILOT_MODEL
Use ask tool to analyze @src/
# Overrides with gpt-5
Use ask tool with model gpt-5 to analyze @src/COPILOT_MCP_CWD - Working DirectoryPurpose: Sets the working directory for Copilot CLI command execution. This is especially important when the MCP server starts from a different directory than your project (e.g., from home directory in IDE integrations).
Method 1: In MCP Configuration (Recommended for IDE)
{
"mcpServers": {
"copilot-cli": {
"command": "npx",
"args": ["-y", "@trishchuk/copilot-mcp-server"],
"env": {
"COPILOT_MCP_CWD": "/absolute/path/to/your/project"
}
}
}
}Method 2: System Environment Variable
# Set for current session
export COPILOT_MCP_CWD=/path/to/your/project
# Permanently (add to ~/.bashrc or ~/.zshrc)
echo 'export COPILOT_MCP_CWD=/path/to/your/project' >> ~/.zshrcResolution Priority:
workingDir parameter in request (highest)
COPILOT_MCP_CWD env variable
PWD or INIT_CWD env variables
Auto-inferred from @path in prompt
process.cwd() (lowest)
Override in requests:
# Use explicit workingDir parameter
Use ask tool with workingDir "/path/to/project" to analyze the codebaseFor IntelliJ IDEA / IDE Users: If Copilot CLI cannot find your project files, set COPILOT_MCP_CWD in your MCP server configuration to point to your project directory.
See Getting Started Guide for full configuration details.
Natural language: "use copilot to explain index.html", "understand this repo with @src", "look for vulnerabilities and suggest fixes"
Claude Code: Type /copilot to access the MCP server tools.
// Use GitHub Copilot CLI for analysis
'explain the architecture of @src/';
// Code review with specific focus
'use copilot to review @src/main.ts for security vulnerabilities';
// Batch processing multiple files
'use batch to refactor all JavaScript files in @src/ for ES6 syntax';
// Comprehensive code review
'use review to perform security review of @api/ with high severity filter';ask copilot to analyze @src/main.ts and explain what it does
use copilot to summarize @. the current directory
analyze @package.json and list dependencies using copilot
ask copilot to explain div centering
ask copilot about best practices for React development
use copilot for TypeScript debugging help
// GitHub Copilot CLI batch processing
'use batch to update all React components in @src/components/ for React 18 patterns';
// Comprehensive code review
'use review for security review of @api/ with critical severity filter and fix suggestions';
// Multiple task processing
'use batch to: 1) add JSDoc comments to @utils.js, 2) fix ESLint issues in @main.ts, 3) update imports in @index.js';brainstorm ways to optimize our CI/CD pipeline using SCAMPER method
use copilot to brainstorm 10 innovative features for our app
ask copilot to generate product ideas for the healthcare domain with design-thinking approach
GitHub Copilot CLI supports tool permissions and directory access controls. This server defaults to allowing all tools for non-interactive mode.
use copilot to create and run a Python script that processes data
ask copilot to safely test @script.py and explain what it does
These tools are designed to be used by the AI assistant.
ask: Executes GitHub Copilot CLI with comprehensive tool and directory management.
Supports @ file references for including file content
Tool permissions: allowAllTools, allowTool, denyTool
Directory access: addDir for granting file system access
Advanced options: logLevel, resume (session management), screenReader support
Session management and logging controls
batch: Processes multiple atomic tasks with GitHub Copilot CLI in batch mode.
Supports parallel or sequential execution
Priority-based task ordering (high, normal, low)
Comprehensive error handling and progress reporting
Stop-on-error or continue-on-error modes
Detailed execution reports with timing and status
review: Comprehensive code review using GitHub Copilot CLI.
Multiple review types: security, performance, code-quality, best-practices, architecture, testing, documentation, accessibility, comprehensive
Severity filtering: low, medium, high, critical
Output formats: markdown, json, text
Fix suggestions and priority ranking
File pattern exclusions and issue limits
brainstorm: Generate novel ideas with structured methodologies.
Multiple frameworks: divergent, convergent, SCAMPER, design-thinking, lateral
Domain-specific context (software, business, creative, research, product, marketing)
Configurable idea count and analysis depth
Includes feasibility, impact, and innovation scoring
Example: brainstorm prompt:"ways to improve code review process" domain:"software" methodology:"scamper"
ping: A simple test tool that echoes back a message.
Use to verify MCP connection is working
Example: /copilot:ping (MCP) "Hello from Copilot MCP!"
Help: Shows CLI help text for GitHub Copilot.
Automatically detects available CLI tools
Displays installation instructions if tools are missing
version: Shows version information for all CLI tools and MCP server.
Reports GitHub Copilot CLI, Node.js, and MCP server versions
Includes installation commands for missing tools
timeout-test: Test tool for timeout prevention.
Runs for a specified duration in milliseconds
Useful for testing long-running operations
You can use these commands directly in Claude Code's interface (compatibility with other clients has not been tested).
/analyze: Analyzes files or directories using Copilot, or asks general questions.
prompt (required): The analysis prompt. Use @ syntax to include files (e.g., /analyze prompt:@src/ summarize this directory) or ask general questions (e.g., /analyze prompt:Please use a web search to find the latest news stories).
/review: Performs comprehensive code review using Copilot.
target (required): Files/directories to review (e.g., /review target:@src/ or /review target:@main.js).
reviewType (optional): Type of review - security, performance, code-quality, etc.
/batch: Processes multiple tasks in batch mode.
tasks (required): Array of tasks to process.
/help: Displays CLI help information for available tools.
/ping: Tests the connection to the server.
message (optional): A message to echo back.
This project was inspired by the excellent work from jamubc/gemini-mcp-tool. Special thanks to @jamubc for the original MCP server architecture and implementation patterns.
Contributions are welcome! Please submit pull requests or report issues through GitHub.
This project is licensed under the MIT License. See the LICENSE file for details.
Disclaimer: This is an unofficial, third-party tool and is not affiliated with, endorsed, or sponsored by GitHub or Microsoft.
Execute GitHub Copilot CLI with file analysis, tool management, and safety controls
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | AI model to use: 'gpt-5', 'claude-sonnet-4', 'claude-sonnet-4.5', or 'claude-haiku-4.5' (0.33x cost). Defaults to COPILOT_MODEL env var or Copilot's default | |
| addDir | No | Add directories to allowed list for file access | |
| banner | No | Show the animated banner on startup | |
| logDir | No | Set log file directory | |
| prompt | Yes | Task or question for GitHub Copilot CLI. Supports @ syntax for files/images (e.g., '@file.png', '@src/') and ! prefix for direct shell commands | |
| resume | No | Resume from a previous session (optionally specify session ID) | |
| noColor | No | Disable all color output | |
| timeout | No | Maximum execution time in milliseconds | |
| continue | No | Resume the most recent session | |
| denyTool | No | Deny specific tools (takes precedence over allowTool) | |
| logLevel | No | Set the log level | |
| allowTool | No | Allow specific tools to run. Supports glob patterns (e.g., 'shell(npm run test:*)') | |
| sessionId | No | Use specific session ID for multi-turn conversations | |
| workingDir | No | Working directory for command execution. Falls back to COPILOT_MCP_CWD env var or process.cwd() | |
| screenReader | No | Enable screen reader optimizations | |
| allowAllPaths | No | Automatically approve access to all file paths (use with caution) | |
| allowAllTools | No | Allow all tools to run automatically (required for non-interactive mode) | |
| disableMcpServer | No | Disable specific MCP servers | |
| additionalMcpConfig | No | Additional MCP server configuration (JSON string or object). Use @ prefix for file path (e.g., "@config.json") | |
| enableSessionTracking | No | Enable session tracking for conversation persistence |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'safety controls' without explaining behaviors, prerequisites, output, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise but not front-loaded with the most critical context; it could be more structured while remaining succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (20 parameters, many optional), the description lacks critical context about what the tool does interactively, output expectations, and multi-turn support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, but the schema covers 100% of parameters with their own descriptions, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes GitHub Copilot CLI with file analysis, tool management, and safety controls, but does not differentiate it from sibling tools like 'batch' or 'review'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives; no explicit when/when-not or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delegate multiple atomic tasks to GitHub Copilot CLI for batch processing. Ideal for repetitive operations, mass refactoring, and automated code transformations
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | AI model to use: 'gpt-5', 'claude-sonnet-4', 'claude-sonnet-4.5', or 'claude-haiku-4.5' (0.33x cost). Defaults to COPILOT_MODEL env var | |
| tasks | Yes | Array of atomic tasks to delegate to GitHub Copilot | |
| addDir | No | Add directories to allowed list for file access | |
| resume | No | Resume from a previous session (optionally specify session ID) | |
| timeout | No | Maximum execution time per task in milliseconds | |
| continue | No | Resume the most recent session | |
| denyTool | No | Deny specific tools | |
| logLevel | No | Set the log level | |
| parallel | No | Execute tasks in parallel (experimental) | |
| allowTool | No | Allow specific tools. Supports glob patterns (e.g., 'shell(npm run test:*)') | |
| workingDir | No | Working directory for command execution. Falls back to COPILOT_MCP_CWD env var or process.cwd() | |
| stopOnError | No | Stop execution if any task fails | |
| allowAllPaths | No | Automatically approve access to all file paths (use with caution) | |
| allowAllTools | No | Allow all tools to run automatically | |
| additionalMcpConfig | No | Additional MCP server configuration (JSON string or object). Use @ prefix for file path (e.g., "@config.json") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states that the tool delegates tasks, but does not mention any side effects, required permissions, error handling, or safety considerations (e.g., that it can modify code or access files). This is insufficient for a powerful batch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences that directly state the tool's function and ideal use cases. No wasted words; every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 15 parameters and no output schema, the description is too minimal. It does not cover important aspects like resume capability, parallel execution, tool control, or failure behavior, leaving the agent without key contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The general description adds no additional parameter-level meaning beyond what is in the schema, nor does it explain parameter interactions or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delegate' and identifies the resource 'multiple atomic tasks to GitHub Copilot CLI', with examples like 'repetitive operations, mass refactoring'. This distinguishes 'batch' from sibling tools like 'ask' or 'review', which are single-turn interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Ideal for repetitive operations' implies a usage context, but the description does not explicitly state when to prefer this tool over alternatives, nor does it mention when not to use it. No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate creative ideas using structured frameworks with domain context and feasibility analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | AI model to use: 'gpt-5', 'claude-sonnet-4', 'claude-sonnet-4.5', or 'claude-haiku-4.5' (0.33x cost). Defaults to COPILOT_MODEL env var | |
| addDir | No | Add directories to allowed list for file access | |
| domain | No | Domain: software, business, creative, research, product, marketing, etc. | |
| prompt | Yes | Brainstorming challenge or question | |
| ideaCount | No | Number of ideas (default: 12, range: 5-30) | |
| workingDir | No | Working directory for command execution. Falls back to COPILOT_MCP_CWD env var or process.cwd() | |
| constraints | No | Limitations: budget, time, technical, legal, etc. | |
| methodology | No | Framework: divergent, convergent, scamper, design-thinking, lateral, auto (default) | auto |
| existingContext | No | Background info or previous attempts | |
| includeAnalysis | No | Include feasibility/impact analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions frameworks and analysis but does not indicate side effects, safety, or whether it's read-only. Only output hints are vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, to the point, but could be more structured with brief usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema, the description is too brief. It doesn't explain return format or how results are presented, omitting critical behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline is 3. Description adds context about structured frameworks and domain context but does not enhance parameter understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates creative ideas using structured frameworks with domain context and feasibility analysis. The verb is specific (generate) and resource is well-defined (creative ideas), with no sibling conflicts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The sibling tools are unrelated, but the description does not help an agent decide context for brainstorming use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Copilot CLI health status including installation, authentication, and session management
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Include detailed diagnostic information | |
| sessionId | No | Check specific session health |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool has side effects, requires authentication, or is read-only. A health check is likely read-only, but that is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose. It is concise and to the point, though it could include brief usage context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the tool returns or its format. Given the tool's purpose, knowing the output structure is important. Additionally, usage guidelines are absent, making it incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The tool description adds the context of 'installation, authentication, and session management' but does not enhance understanding of the parameters beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'Copilot CLI health status', and specifies included areas (installation, authentication, session management). This distinguishes it from sibling tools like 'ping' or 'version'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives, nor does it mention any exclusions or prerequisites. For a health check tool, it should clarify when to use 'health' vs 'ping' for connectivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
receive help information for Copilot CLI
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'receive help information' without mentioning read-only nature, side effects, or output format, providing no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly terse (one sentence) and lacks front-loaded key details. While concise, it sacrifices clarity and usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema or annotations, the description should compensate. It fails to explain what help content is provided or how it is structured, leaving the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline score of 4 is appropriate since the description adds no parameter info but the schema is already complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides help information for Copilot CLI, which is clear but generic. It does not differentiate from sibling tools like 'ask' or 'review' that might also offer guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'ask' or 'review'. The description lacks explicit context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, delete, or clear session data for multi-turn conversations
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Action to perform: list, delete, or clear | list |
| sessionId | No | Session ID for delete action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits such as destructive nature of delete/clear actions, authentication requirements, or data retention policies. The actions are listed without warnings or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose. It is front-loaded and contains no fluff, making it easy to parse. However, it could be slightly more structured to separate actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description provides adequate context that it handles session management. However, it omits details about parameter dependencies (e.g., sessionId only for delete) and output format, leaving room for misinterpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameter meanings. The description does not add meaningful semantics beyond what the schema provides, merely restating the actions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool can list, delete, or clear session data for multi-turn conversations. It uses specific verbs and identifies the resource (session data), distinguishing it from sibling tools which cover different functionalities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for managing session data, but provides no explicit guidance on when to use it versus other tools or when not to use it. No alternatives are mentioned, which is acceptable given sibling diversity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Echo
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Message to echo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Echo' only restates the core action and implies the prompt is returned, but it does not state side effects, safety traits, or response format. For a trivial tool this is minimally acceptable, but it still lacks explicit behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise, it is under-specified rather than efficiently structured. A single word without context is not a well-formed definition, and the conciseness is the result of omission rather than careful pruning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's low complexity, the description leaves out important context such as the intended use (e.g., connectivity test or echo of user input) and the fact that the given prompt will be returned. There is no output schema, so the description should clarify return behavior, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with the description 'Message to echo' for the prompt parameter. The description 'Echo' adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a single word, 'Echo', which names an action but does not specify the resource or what is echoed. It is not a complete statement of purpose and leaves ambiguity about whether it echoes the prompt parameter or something else. This is more like a vague fragment than a clear tool definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus any of the sibling tools. There is no mention of typical use cases, prerequisites, or exclusions. An agent receives no context to decide whether to call ping instead of ask-gemini or brainstorm.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprehensive code review using GitHub Copilot CLI with multiple review types (security, performance, quality, etc.) and detailed reporting
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | AI model to use: 'gpt-5', 'claude-sonnet-4', 'claude-sonnet-4.5', or 'claude-haiku-4.5' (0.33x cost). Defaults to COPILOT_MODEL env var | |
| addDir | No | Directories to grant access | |
| resume | No | Resume from a previous session (optionally specify session ID) | |
| target | Yes | Target files/directories to review | |
| timeout | No | Maximum execution time in milliseconds | |
| continue | No | Resume the most recent session | |
| severity | No | Minimum severity level to report | |
| maxIssues | No | Maximum number of issues to report | |
| reviewType | No | Type of review to perform | comprehensive |
| workingDir | No | Working directory for command execution. Falls back to COPILOT_MCP_CWD env var or process.cwd() | |
| outputFormat | No | Output format for the review | markdown |
| allowAllPaths | No | Automatically approve access to all file paths (use with caution) | |
| allowAllTools | No | Allow all tools for comprehensive analysis | |
| excludePatterns | No | File patterns to exclude | |
| additionalMcpConfig | No | Additional MCP server configuration (JSON string or object). Use @ prefix for file path (e.g., "@config.json") | |
| includeFixSuggestions | No | Include specific fix suggestions | |
| includePriorityRanking | No | Include priority ranking for issues |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'comprehensive code review' but fails to explain that it requires file access, executes commands, or produces a report with issues. The behavioral impact is under-disclosed given the complex parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key purpose. While concise, it could be more informative by adding a second sentence on output or usage. Still, it is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters and no output schema, the description should clarify the output format and what 'detailed reporting' entails. It lacks information on return values, typical usage flow, and file access implications, making it incomplete for an agent to fully anticipate tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described, so the baseline is 3. The description previews review types (security, performance, etc.) which aligns with the reviewType enum, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs comprehensive code review using GitHub Copilot CLI with multiple review types and detailed reporting. It effectively distinguishes from sibling tools like 'ask' or 'brainstorm' by specifying its focus on code analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for code review but does not explicitly state when to use versus alternatives like 'ask' or 'batch'. No exclusions or when-not context is provided, making it adequate but lacking explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test timeout prevention by running for a specified duration
| Name | Required | Description | Default |
|---|---|---|---|
| duration | Yes | Duration in milliseconds (minimum 10ms) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the tool runs for a specified duration but lacks details on side effects, return values, or whether it is read-only or destructive. This is insufficient for a tool that likely involves waiting or blocking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. Every word contributes to the core message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential idea. However, it lacks context on what 'timeout prevention' means, typical use cases, and expected behavior after the duration elapses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (duration parameter already described). The description adds no additional meaning beyond 'running for a specified duration', which is already implied by the parameter name. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test timeout prevention by running for a specified duration'. It uses a specific verb ('Test') and resource ('timeout prevention'), distinguishing it from sibling tools like 'ping' or 'health'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for testing timeout prevention but provides no explicit guidance on when to use this tool vs alternatives. No exclusions or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display version and system information for Copilot and MCP server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that the tool displays information, which is benign. However, it does not elaborate on whether there are any side effects, data sensitivity, or specific behaviors beyond the stated output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose without waste. It is front-loaded and every word is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and a straightforward purpose, the description adequately covers its function. However, it lacks detail on the exact output format, which might be incomplete without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so per the rubric, baseline is 4. The description adds no parameter-specific meaning because there are none, but schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool displays version and system information for Copilot and MCP server. It uses a specific verb ('Display') and identifies the resource ('version and system information'). This distinguishes it from sibling tools like 'ping' (connectivity) and 'health' (overall system health).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'health' or 'ping'. It only states what the tool does, with no context about appropriate scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.4.0askbatchbrainstormhealthHelplist-sessionspingreviewtimeout-testversionScored across 10 tools
Most tools have distinct purposes. However, 'ask' and 'batch' both involve executing tasks via Copilot CLI, which could cause confusion; 'ask' is for single tasks with file analysis, while 'batch' is for multiple atomic tasks.
Naming is inconsistent: 'Help' is capitalized while others use lowercase; 'timeout-test' uses a hyphen; 'list-sessions' uses underscores. There is no consistent verb_noun or verb-noun pattern.
With 10 tools, the server is well-scoped for its purpose as a Copilot CLI wrapper. Each tool serves a distinct function without unnecessary bloat.
The tool surface covers the main functionalities: getting help, version info, executing tasks (single and batch), code review, brainstorming, health checks, and session management. Missing a dedicated 'chat' or 'explain' tool, but 'ask' likely handles that.
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
Share one project context across ChatGPT, Claude, Telegram and any MCP client.
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
