Skip to main content
Glama
Jaggerxtrm

Rovodev MCP Tool

by Jaggerxtrm
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Rovodev MCP Tool

Model Context Protocol server for Atlassian Rovo Dev CLI integration. This tool enables AI assistants like Claude to leverage Rovo Dev's powerful code analysis and capabilities through the MCP protocol.

Rovo Dev is a comprehensive AI coding assistant that already includes built-in MCP support. This tool allows Rovo Dev to be used as an external tool from other MCP-compatible AI assistants, creating a bridge between different AI tools.

Features

  • Large Context Windows: Leverage Rovo Dev's powerful AI capabilities for analyzing large files and entire codebases

  • File Analysis: Use @filename or @directory syntax to include file contents in your queries

  • Multiple Models: Support for various AI models configured in Rovo Dev (default: anthropic.claude-sonnet-4-5-20250929-v1:0)

  • Flexible Approval Modes: Control tool execution with plan/default/auto-edit/yolo modes

  • MCP Protocol: Seamless integration with MCP-compatible AI assistants

  • Rovo Dev Specific Features: Includes support for code mode, review mode, optimization suggestions, and detailed explanations

Related MCP server: Moatless MCP Server

Prerequisites

  • Node.js v16 or higher

  • acli rovodev installed and configured (Atlassian Rovo Dev CLI)

Installation

Prerequisites

First, ensure you have Rovo Dev CLI installed and configured:

# Follow Rovo Dev installation instructions to install acli rovodev
# Configure your models and authentication in ~/.rovodev/config.yml

Quick Setup (Easiest - Recommended)

Use Claude Code's built-in MCP installer:

claude mcp add rovodev-cli -- npx -y @jaggerxtrm/rovodev-mcp-tool

This single command configures everything automatically!

Manual Configuration for Rovo Dev

Since Rovo Dev already has MCP support, you can add this tool to your existing Rovo Dev configuration:

Edit ~/.rovodev/config.yml and add to the allowedMcpServers list:

mcp:
  allowedMcpServers:
  - stdio:npx:-y @jaggerxtrm/rovodev-mcp-tool  # Add this line

Or add to ~/.rovodev/mcp.json:

{
  "mcpServers": {
    "...": "...",
    "rovodev-cli": {
      "command": "npx",
      "args": [
        "-y",
        "@jaggerxtrm/rovodev-mcp-tool"
      ]
    }
  }
}

From Source (Development)

  1. Clone and install dependencies:

git clone <repo-url>
cd rovodev-mcp-tool
npm install

  1. Build the project:

npm run build

  1. Link locally:

npm link

Available Tools

ask-rovodev

The main tool for interacting with Rovodev AI.

Parameters:

  • prompt (required): Your question or instruction

    • Use @filename to include a file's contents

    • Use @directory to include all files in a directory

  • model (optional): Model to use (default, advanced, basic, etc.)

  • approvalMode (optional): Control tool execution approval

    • plan: Analyze tool calls without executing

    • default: Prompt for approval (default behavior)

    • auto-edit: Auto-approve file edits

    • yolo: Auto-approve all tool calls

  • yolo (optional): Shortcut for approvalMode='yolo'

  • allFiles (optional): Include all files in current directory as context

  • debug (optional): Enable debug mode

Examples:

// Analyze a specific file
{
  "prompt": "@src/main.ts Explain what this code does"
}

// Analyze entire codebase
{
  "prompt": "@src/ Summarize the architecture of this codebase"
}

// Use specific features
{
  "prompt": "Review my authentication system for security issues",
  "reviewMode": true,
  "explain": true
}

// Optimize code
{
  "prompt": "How can I optimize this algorithm?",
  "optimize": true,
  "explain": true
}

ping

Simple echo test to verify the connection.

Parameters:

  • prompt (optional): Message to echo (defaults to "Rovodev Pong!")

Help

Display Rovodev CLI help information.

Parameters: None

Configuration

The tool uses the following default models:

  • Primary: default

  • Fallback: basic (used if primary hits quota limits)

You can override these by specifying the model parameter in your requests.

Usage with Claude Code

Once installed as an MCP server, you can use it within Claude Code:

Ask Rovodev to analyze the authentication system in @src/auth/

Claude will automatically use the ask-rovodev tool with the appropriate parameters.

Project Structure

rovodev-mcp-tool/
├── src/
│   ├── index.ts              # MCP server entry point
│   ├── constants.ts          # Configuration and constants
│   ├── tools/
│   │   ├── registry.ts       # Tool registration system
│   │   ├── ask-rovodev.tool.ts  # Main Rovodev interaction tool
│   │   ├── simple-tools.ts   # Utility tools (ping, help)
│   │   └── index.ts          # Tool exports
│   └── utils/
│       ├── commandExecutor.ts # Command execution utility
│       ├── rovodevExecutor.ts    # Rovodev CLI wrapper
│       └── logger.ts          # Logging utility
├── package.json
├── tsconfig.json
└── README.md

How It Works

  1. The MCP server listens for tool calls via stdio transport

  2. When a tool is called, the server validates the arguments using Zod schemas

  3. For ask-rovodev, the prompt is passed to the acli rovodev run command with appropriate flags

  4. File references (@filename) are processed by Rovo Dev's built-in file processing

  5. Output from Rovo Dev is captured and returned to the MCP client

  6. The tool integrates with Rovo Dev's existing configuration and model settings

Troubleshooting

"acli rovodev not found"

Make sure the acli rovodev command is installed and available in your PATH.

"Command timed out"

For very large files or codebases, the analysis may take longer than the default 10-minute timeout. Consider:

  • Using .rovodevignore to exclude unnecessary files

  • Breaking down large queries into smaller chunks

  • Using approvalMode: "plan" to analyze without executing

"Invalid tool arguments"

Check that your arguments match the tool schema. Use the Help tool to see available options.

License

MIT

Contributing

Contributions are welcome! Please feel free to submit issues or pull requests.

Credits

Inspired by qwen-mcp-tool and gemini-mcp-tool.

Available Tools

3 tools
ask-rovodevC

Query Rovodev AI with support for file analysis (@file or #file syntax), codebase exploration, and large context windows. Supports various models and execution modes.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe query or instruction for Rovodev. Use @filename, #filename, or directory references to include file contents. Example: '@src/ Explain this codebase structure'
modelNoOptional model to use (e.g., 'default'). If not specified, uses the default model (default).
sandboxNoUse sandbox mode to safely test code changes, execute scripts, or run potentially risky operations in an isolated environment
approvalModeNoControl tool execution approval: 'plan' (analyze only), 'default' (prompt for approval), 'auto-edit' (auto-approve edits), 'yolo' (auto-approve all)
yoloNoEnable YOLO mode to automatically approve all tool calls without prompting (equivalent to approvalMode='yolo')
allFilesNoInclude all files in the current directory as context (use with caution for large directories)
debugNoEnable debug mode for more verbose output
codeModeNoEnable code-specific analysis mode for better code understanding
reviewModeNoEnable code review mode for detailed feedback
optimizeNoRequest optimization suggestions for the code
explainNoRequest detailed explanations of code functionality

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions capabilities like file analysis and large context windows, it lacks critical behavioral details: whether this is a read-only or mutating operation, authentication requirements, rate limits, response format, or error handling. The description covers what the tool can do but not how it behaves operationally.

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 appropriately concise - a single sentence that efficiently lists key capabilities. It's front-loaded with the core purpose and doesn't waste words. However, it could be slightly more structured by separating distinct capability categories more clearly.

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

Completeness2/5

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

For a complex tool with 11 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what kind of response to expect, error conditions, operational constraints, or how the various parameters interact. The description covers 'what' but not 'how' or 'what happens next,' leaving significant gaps for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 11 parameters thoroughly. The description adds minimal parameter semantics beyond what's in the schema - it mentions '@file or #file syntax' which relates to the 'prompt' parameter, but doesn't provide additional context about parameter interactions or advanced usage patterns. Baseline 3 is appropriate when 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 the tool's purpose: 'Query Rovodev AI with support for file analysis, codebase exploration, and large context windows.' It specifies the action (query), target (Rovodev AI), and key capabilities. However, it doesn't explicitly differentiate from sibling tools like 'Help' or 'ping' beyond the AI query focus.

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 mentions general capabilities but provides no guidance on when to use this tool versus alternatives. There's no mention of when to choose this over sibling tools like 'Help' or 'ping', nor any context about appropriate use cases versus other query methods. Usage is implied through feature listing rather than explicit guidance.

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

HelpB

Display rovodev CLI help information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool displays help information, implying a read-only, informational operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, or what format the help is in (e.g., text, markdown). This leaves gaps in understanding how the tool behaves beyond its basic purpose.

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, clear sentence: 'Display rovodev CLI help information.' It is front-loaded with the core action and resource, with zero wasted words. Every part of the sentence earns its place by specifying what is displayed and in what context.

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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It states what the tool does but lacks details on behavioral aspects like output format or usage context. For a help tool, this might suffice minimally, but more completeness could improve agent understanding, especially without annotations.

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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids mentioning any. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce confusion by referencing non-existent inputs.

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's purpose: 'Display rovodev CLI help information' specifies the action (display) and resource (help information) with context (CLI). It doesn't explicitly distinguish from sibling tools like 'ask-rovodev' or 'ping', but the purpose is unambiguous for a help function.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like needing CLI documentation, troubleshooting, or how it differs from 'ask-rovodev' (which might provide interactive help). Without such context, users must infer usage based on the tool name alone.

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

pingB

Echo a message to test the connection

ParametersJSON Schema
NameRequiredDescriptionDefault
promptNoMessage to echoRovodev Pong!

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool 'echoes a message', which implies a read-only or simple response behavior, but it doesn't disclose details like whether it requires authentication, has rate limits, or what the exact output format is. For a tool with no annotation coverage, this is a significant gap in behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's function without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

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 low complexity (one optional parameter) and high schema coverage, the description is adequate but has clear gaps. It lacks output schema information and doesn't fully compensate for the absence of annotations, leaving behavioral aspects like response format or error handling unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents the single parameter 'prompt' with its type, default value, and description. The tool description doesn't add any additional meaning beyond what the schema provides, such as usage examples or constraints, which aligns with the baseline score when 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 the tool's purpose with a specific verb ('echo') and resource ('a message'), explaining it's for testing connections. However, it doesn't explicitly differentiate from sibling tools like 'ask-rovodev' or 'Help', which might also involve communication or testing functions.

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 testing connections, which provides some context, but it doesn't specify when to use this tool versus alternatives like 'ask-rovodev' or 'Help'. No explicit when-not-to-use guidance or prerequisites are 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. Dates show when Glama detected each change.

  1. 3 tool updates
    • First observedask-rovodev
    • First observedHelp
    • First observedping
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: ask-rovodev is for AI-powered querying with file analysis, Help provides CLI documentation, and ping is for connection testing. There is no overlap in functionality, making tool selection unambiguous.

Naming Consistency2/5

Naming is inconsistent: ask-rovodev uses kebab-case with a verb-noun structure, Help uses PascalCase (or title case) with a noun only, and ping uses lowercase with a verb only. There is no predictable pattern across the tool set.

Tool Count3/5

With only 3 tools, the set feels thin for a server named 'Rovodev MCP Tool', which suggests broader capabilities. However, the tools cover basic AI querying, help, and connectivity, so it's borderline but not severely mismatched.

Completeness2/5

Inferred domain is AI-assisted development or code analysis, but the tool surface is significantly incomplete. There are no tools for operations like code generation, debugging, version control integration, or configuration management, which are typical in such domains, leading to potential agent failures.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • ccg-mcp-tool

    diaz3618
    A
    license
    B
    quality
    C
    maintenance
    This is a powerful Model Context Protocol (MCP) server that integrates multiple AI coding agents—Anthropic Claude Code, OpenAI Codex, and Google Gemini—directly into your workflow. It enables seamless cross-provider analysis, leveraging Gemini's massive token window, Codex's specialized coding capabilities, and Claude's advanced reasoning.
    10
    19
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jaggerxtrm/rovodev-mcp-tool'

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