The LocalMcpTools server currently exposes a single read-only inspection tool, workspace.inspect, which serves as a stub to verify end-to-end MCP stdio communication. It returns the server PID and build label and accepts an optional placeholder boolean (ignored). No other tools are implemented yet. The project roadmap (per README) includes planned surfaces for:
Environment inspection (environment.*)
File system inspection (fs.*)
Output inspection (output.*)
Shell control (shell.*) with approval/deny rules
Managed development server lifecycle (process.*) supporting presets like python-uvicorn, node-vite, node-next-dev, dotnet-run, with start, stop, status, port listing, and port-based lookup. Managed processes are designed for lifecycle-bound termination, but arbitrary process killing is not exposed.
These planned capabilities are not yet available; only
workspace.inspectis currently functional.
Click on "Install 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., "@LocalMcpTools what files are in the workspace?"
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.
A local Model Context Protocol (MCP) toolset for VS Code agents (codebuddy, GitHub Copilot, and others).
Phases 0-6 (ui-automation-and-ocr) code-complete. E2E test
suite covers phases 1, 2, 3, 4, 5, 6, 7, 8, 9 (243 tests, ~4 min).
Live spike accuracy numbers + the cross-agent live hand-off
check still owed.
What's shipped:
Read-only diagnostics: environment.get, workspace.register / list / inspect / search_text / git_status, fs.read_range / tail_log_file / grep_files, output.tail / read_range / search, runtime.detect_runtime / get_env / list_path, vscode.get_problems / get_installed_extensions / get_logs / get_debug_sessions, diagnostics.collect / explain_failure.
Controlled side effects: shell.run_command, workspace.run_test / build / lint, with server-side observe / workspace_exec profile gating
one-time human approvals + 10 built-in deny rules (Format-Volume, Format/diskpart, cipher /w, rm-system, bcdedit/bootrec, netsh reset, registry HKLM, privilege escalation, kill-protected, RDP enable, remote-download-exec).
Lifecycle-bound dev servers: process.start_dev_server / get_status / list_managed / stop_managed / list_listening_ports / find_by_port. Children are attached to a Windows Job Object so they die
with the server.
HTTP control plane: localmcptools start --http boots a FastAPI app
on 127.0.0.1:7890 (configurable) with Origin allowlist, CSRF
double-submit, bearer auth for /mcp (Streamable HTTP MCP transport,
same protocol as stdio), and 16 control endpoints
(/api/status, /api/audit, /api/rules, /api/backgrounds,
/api/settings, /api/mcp-config-snippet, /api/windows/*,
/api/shutdown, ...).
Angular SPA: Dashboard / Audit / Settings / Rules / MCP-config /
Automation pages under ui/. Build with scripts/build_frontend.bat;
the bundle lands in src/localmcptools/ui_assets/ and is served at /ui/.
UI automation + OCR: ui.list_windows / authorize_window / get_ui_tree / find_element / screenshot_{window,full,region} / click_element / type_text / act_and_verify and
ocr.ocr_region / find_text / assert_text with a Windows OCR
provider that falls back to a stub on hosts without winsdk.
Verification harness (UIA / screenshot / OCR predicates).
Packaging: localmcptools install [--method scheduled_task|startup_folder]
registers a user-level (no admin) Windows scheduled task; uninstall
removes it. Idempotent.
E2E test suite (tests/e2e/): 243 tests covering 7 of the 13 plan
phases — boot, tool surface (stdio + HTTP), HTTP control plane,
policy enforcement, artifact redaction, workspace lifecycle,
managed-process lifecycle, and concurrent clients. Run with
pytest -m e2e. See docs/e2e-plan.md.
What's still owed: live Windows OCR accuracy spike (provider ships but
real numbers haven't been measured yet), the cross-agent live
hand-off check for workbuddy / minimax code, the Windows reboot
smoke test for the scheduled task, and e2e phases 10-13 (Angular UI
playwright, UI automation, OCR, install/uninstall). See
openspec/changes/ for the contracts and
docs/implementation-plan.md for the full
roadmap.
Related MCP server: VSCode Context MCP
# Start the FastAPI app + control plane + UI on the loopback.
localmcptools start --http --port 7890 --auto-open-browser
# In another shell: build the Angular SPA so the static mount has content.
scripts\build_frontend.bat # runs `npm install` if needed, then `ng build --prod`
# Browse to http://127.0.0.1:7890/ui/Bearer secret for /mcp is generated at boot and stored in
%APPDATA%\LocalMcpTools\server.json next to the bound port.
CSRF double-submit protects every unsafe /api/* request; the SPA
fetches /api/csrf-token on first load and includes the
X-LMCP-CSRF header from then on.
# 1. Create a venv and install (editable, so src changes are live).
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e .
.\.venv\Scripts\python.exe -m pip install -r requirements-dev.txt
# 2. Run the tests.
.\.venv\Scripts\python.exe -m pytest
# 3. Launch the server (it blocks on stdio, waiting for an MCP client).
.\.venv\Scripts\python.exe -m localmcptoolsBoth codebuddy and VS Code's GitHub Copilot Chat discover MCP servers
through a JSON file the IDE watches. The sample files in
samples/ show the spike configuration; copy the relevant one
into the location your agent expects.
Agent | Where the file goes (Windows) | Sample |
codebuddy |
| |
GitHub Copilot Chat (VS Code) |
|
The configuration is identical for both agents — both speak the standard MCP
stdio transport. Once codebuddy / Copilot reads the file, the tool list
includes the environment.*, workspace.*, fs.*, output.*, shell.*,
and process.* surfaces.
process.start_dev_server accepts only the built-in python-uvicorn,
node-vite, node-next-dev, and dotnet-run presets. It requires a workspace
with the managed_process profile and a matching one-time approval. Use
process.get_status, process.list_managed, process.stop_managed,
process.list_listening_ports, and process.find_by_port to observe and stop
owned processes. Arbitrary process.kill(pid) is intentionally not exposed.
Managed process output is available immediately through the returned Artifact handle. On Windows, child trees are attached to a kill-on-close Job Object, so they are terminated when the MCP server exits.
Runtime state (audit log, settings, logs) lives under
%APPDATA%\LocalMcpTools\ by default. Override with the
LMCP_DATA_DIR environment variable for tests or portable installs.
# Register a user-level scheduled task. No admin required.
localmcptools install
# Or, if scheduled-task creation fails, drop a .lnk in the Startup folder.
localmcptools install --method startup_folder
# To remove
localmcptools uninstallThe task boots python -m localmcptools start from the repo root at user
logon, with RestartCount=3, RestartInterval=1min so transient failures
self-heal. The scheduled task never runs elevated, so it cannot affect
other users.
See docs/agent-configuration.md for the
per-agent mcp.json locations and snippets (codebuddy, GitHub Copilot,
workbuddy, minimax code — last two marked "untested" until those agents
ship a public MCP spec).
Workspace inspection spike stub. Confirms the MCP stdio round-trip end-to-end. Returns the server pid and build label so the caller can verify the call landed. Accepts an optional 'placeholder' field and ignores it.
| Name | Required | Description | Default |
|---|---|---|---|
| placeholder | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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. It explicitly states that the tool ignores the 'placeholder' parameter and returns the server pid and build label, which is honest and sufficient for a simple stub. There is no mention of side effects or error conditions, but the tool's trivial nature makes that a minor gap.
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 long, front-loaded with the key concept ('spike stub'), and contains no redundant information. Every sentence contributes meaning: the purpose, the return values, and the parameter handling.
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 tool is a simple stub with a single optional parameter and no siblings. The description covers the purpose, return values, and parameter behavior. An output schema is present, and the description mentions pid and build label, which likely appears in that schema, so no critical information is missing.
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 zero description coverage (0%), but the description fully compensates by stating that the 'placeholder' field is optional and ignored. This completely explains the only parameter's semantics, adding value beyond the bare 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 that this is a 'spike stub' to confirm the MCP stdio round-trip and that it returns the server pid and build label. While the name 'Inspect workspace' could be misleading, the description immediately clarifies its actual testing purpose. There are no sibling tools, so differentiation is not explicitly needed.
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 as a connectivity test by saying it 'confirms the MCP stdio round-trip end-to-end.' However, it does not explicitly state when to use or not use this tool, nor does it mention alternatives. The 'spike stub' label provides some implicit context that this is a temporary/testing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Only one tool exists, so there is no possibility of confusion between tools. The purpose, while a stub, is clearly described.
The single tool uses a dotted namespace convention, which is internally consistent. There are no other tools to compare against, so no inconsistencies exist.
With exactly one tool that serves as a spike stub, the server is extremely thin and does not justify a multi-tool MCP server. The tool count is far too low for any meaningful workspace inspection.
The tool is explicitly a stub and does not perform any actual workspace inspection. The domain implied by the name is not covered at all, representing a severe incompleteness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for building and testing AI agents with multi-model experimentation and insights.
An MCP server that gives your AI access to the source code and docs of all public github repos
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jzhong2026/LocalMcpTools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
