Integrates with GitHub Copilot in VS Code to provide project automation, language management, file system search, and system utilities for AI-assisted development.
Integrates with Google Antigravity to enable AI agents to run commands, manage projects, and navigate the file system.
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., "@obox-mcp Find all Python files with TODO comments"
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.
Click the image to watch the video tutorial.
English | TiαΊΏng Viα»t
This guide explains how to install and integrate Obox MCP into your coding environment.
Obox MCP is a comprehensive development toolkit designed to supercharge your IDE. It provides:
Project Automation: Manage dependencies and run tasks with just.
Language Tools: Manage Node.js, Python, and .NET environments.
File System: Advanced file search and navigation with fd and ripgrep.
System Utilities: Cross-platform installers and shell integration.
LLMs are isolated execution environments. They cannot see your system or run code. You get:
β Manual Execution: The AI code suggests commands, but you have to switch to the terminal to run them.
β Blind Guessing: The AI hallucinates file paths or project structures it can't see.
β Outdated Context: You have to manually copy-paste file contents for the AI to understand your project.
Obox MCP gives your AI agent hands and eyes. It can autonomously run commands, manage files, and navigate your project without you lifting a finger.
Add use obox to your prompt:
"Find all Python files containing 'TODO' and list their locations."
"Initialize a new FastAPI project, install dependencies, and run the server."
Obox MCP fetches real-time project info, executes complex build tasks, and manages your environment directly. No tab-switching, no manual copy-pasting, just results.
Related MCP server: Nexus-MCP
Obox MCP is optimized to run using Astral uv. Ensure you have uv installed on your system:
# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh# Windows (PowerShell)
powershell -c "Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force"
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"Go to: Settings -> Cursor Settings -> General -> MCP -> Add new global MCP server.
Paste the following configuration into your Cursor ~/.cursor/mcp.json file.
{
"mcpServers": {
"obox": {
"command": "uv",
"args": [
"run",
"--project",
"/absolute/path/to/obox",
"/absolute/path/to/obox/main.py"
]
}
}
}Open Command Palette (Ctrl+Shift+P / Cmd+Shift+P).
Type: MCP: Open User Configuration.
Paste the content into the file.
{
"servers": {
"obox": {
"type": "stdio",
"command": "uv",
"args": [
"run",
"--project",
"/absolute/path/to/obox",
"/absolute/path/to/obox/main.py"
]
}
}
}Run the following command in your terminal to add the MCP server:
claude mcp add obox -- uv run --project /absolute/path/to/obox /absolute/path/to/obox/main.pyAdd this to your claude_desktop_config.json:
{
"mcpServers": {
"obox": {
"command": "uv",
"args": [
"run",
"--project",
"/absolute/path/to/obox",
"/absolute/path/to/obox/main.py"
]
}
}
}Open Command Palette (Ctrl+Shift+P / Cmd+Shift+P).
Type: Antigravity: Manage MCP Servers.
Click View Raw Config.
Paste the content into the file.
{
"mcpServers": {
"obox": {
"command": "uv",
"args": [
"run",
"--project",
"/absolute/path/to/obox",
"/absolute/path/to/obox/main.py"
]
}
}
}To avoid typing use obox in every prompt, add a rule to your MCP client to automatically invoke Obox tools for development tasks.
Recommendation: Copy the content of .github/copilot-instructions.md into:
Cursor: Cursor Settings > Rules
Claude Code: CLAUDE.md
Other Clients: The equivalent system prompt or rules setting.
Finalizes project setup by detecting structure. Call this tool immediately after creating any new project.
| Name | Required | Description | Default |
|---|---|---|---|
| root_working_directory | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 says 'detecting structure' without disclosing side effects, preconditions, or what the tool modifies. The agent cannot predict the tool's behavior confidently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff and front-loaded. It is concise and well-structured, though the brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it has an output schema but no annotations, the description fails to explain what 'finalizes project setup' does, what structure detection involves, or what the output contains. The description is too minimal for an agent to understand the tool's complete contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (root_working_directory) with no description, and the tool description doesn't mention it at all. With 0% schema description coverage, the agent has zero semantic understanding of this parameter.
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 a clear action ('Finalizes project setup') and resource, and distinguishes from sibling tools (init_project) by indicating this is a post-creation step. However, 'finalizes' is somewhat vague and doesn't specify what the finalization entails.
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?
Provides explicit when-to-use guidance: 'Call this tool immediately after creating any new project.' This makes the invocation context clear. It doesn't mention when not to use it or alternatives, but the instruction is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initializes a new FastAPI project at the specified path. Sets up uv environment with the specified Python version and installs fastapi[standard].
Args: path: The absolute path where the project should be initialized. python_version: The Python version to use (default: "3.12").
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| python_version | No | 3.12 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the key actions: initializing a project, setting up a uv environment, and installing fastapi[standard]. While it does not detail side effects like overwriting or network requirements, it provides meaningful behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the primary purpose stated in the first sentence. The Args section is structured and provides necessary details without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and all parameters, and an output schema exists so return details are omitted. It lacks explicit preconditions (e.g., whether the path must be empty) but is adequate for a project initialization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description's Args section explains both parameters: path is an absolute path, and python_version is the Python version with a default of '3.12'. This fully compensates for the schema's lack of semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: 'Initializes a new FastAPI project at the specified path.' It also details the setup steps (uv environment, FastAPI installation), making it distinct from sibling tools like react_init_project.
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 FastAPI project initialization but does not explicitly mention when to use it versus alternatives or provide exclusions. Usage context is inferred from the tool name and description rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initializes a new React project at the specified path. Setup includes:
Vite (React + TypeScript)
Tailwind CSS v4
TanStack Query
Tabler Icons React
Args: path: The absolute path where the project should be initialized.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the setup contents but lacks critical details such as whether existing files will be overwritten, whether the path must be empty, or whether network access is required. These omissions leave safety and side-effect behavior unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement, a compact bullet list of dependencies, and an explicit Args section for the parameter. Every line contributes to understanding, with no redundant information.
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 an output schema, the description adequately covers the core purpose and setup details. However, it omits behavioral prerequisites and side effects, which are important for an initialization tool. The presence of an output schema reduces the need to describe return values, but the missing safety context slightly lowers completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'path' parameter, but the description clarifies that it expects an absolute path, which adds meaningful semantics. While it could include constraints like 'must be empty' or 'will create directory', the current explanation is sufficient for a single-parameter tool.
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 initializes a new React project at a specified path and lists the specific technologies included (Vite, Tailwind CSS, TanStack Query, Tabler Icons). This distinguishes it from sibling tools like obox_fastapi_init_project, which is focused on FastAPI.
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 creating a React project with the listed technologies but does not explicitly state when to use it or when not to. It does not reference sibling tools or provide alternative tool suggestions, leaving usage context only implicit.
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.
v0.1.0just_project_runnerobox_fastapi_init_projectreact_init_projectScored across 3 tools
Each tool has a clearly distinct purpose: one initializes FastAPI, one initializes React, and one finalizes any newly created project. There is no functional overlap between them.
The two initialization tools follow a similar pattern (framework_init_project), but the finalizer tool (just_project_runner) uses a completely different naming style. Additionally, one tool has the 'obox_' prefix while the other does not, causing inconsistency.
Three tools is a well-scoped count for a project scaffolding server. Each tool serves a distinct purpose and the count is within the ideal 3-15 range.
The tool set covers the init and finalize lifecycle for FastAPI and React, but lacks support for other common frameworks and has no additional operations like listing projects or managing dependencies. The finalizer is somewhat disconnected from the init tools, requiring manual invocation.
Hyperion β MCP tool marketplace for AI agents: web, OSINT, security, research via one key.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AgentPMT is the AI agent marketplace that turns any MCP-compatible AI assistant into an autonomous employee. Connect once and your agents gain access to a growing ecosystem of tools, workflows, and skills spanning communication, data analytics, development, file management, search, and more. AgentPMT dynamically discovers and orchestrates tools from across the MCP ecosystem, so your agents can independently find the right tool for any task without manual configuration.
MCP-first toolbox for agents: KV storage, auth, queue, and utility tools. Free in early access.