What can you do with this server?

You can perform file operations, run shell commands, and get system info on the host machine. * Read files (full or line range) via fs_read. * Create or overwrite files via fs_write. * Edit files by exact substring replacement via fs_edit. * List files and directories up to a given depth via fs_list. * Find files by glob and grep file contents via fs_search. * Execute arbitrary shell commands with optional cwd and timeout via shell_exec. * Get OS, CPU, memory, user, and workspace info via sys_info.

How do I use NotiCode?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NotiCode create a new file named 'test.py' that prints 'Hello'" 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.

NotiCode

by Antropov31

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

NotiCode

The blue, MCP-native AI agent for your whole machine.

Runs as an MCP server so Claude (or any MCP client) can plug in, chat, and let it edit files and drive your machine. DM it on Telegram. Or run everything at once and control one shared agent from your MCP client and your phone.

What is this?

NotiCode is an open AI agent in the spirit of OpenCode and Claude Code, with one twist: it speaks MCP first.

It has hands. It can read/write files, run shell commands, inspect your system, drive a headless browser, take screenshots and webcam photos, control your Home Assistant smart home, schedule recurring jobs, and message you on Telegram (text and photos). Connect it to an MCP client, talk to it in your terminal, or DM the Telegram bot, all backed by the same toolset.

It is blue. Not orange. On purpose.

Related MCP server: vulcan-file-ops

The one-command setup: `all`

node dist/index.js all
# or: npm run all

This boots everything in a single process:

the HTTP MCP server (prints a URL you paste into any MCP client),
the Telegram bot (DM it from your phone),
the scheduler (cron jobs that notify you when done).

They all share the same tools and workspace. So you can text the bot "измени мои файлы" / "edit my files and run the tests", or type the same thing into an MCP client, and the same agent does the work on the same machine. Needs ANTHROPIC_API_KEY (for the bot) and TELEGRAM_BOT_TOKEN (to enable Telegram); the HTTP server and scheduler run even without them.

Do I need an API key?

noticode mcp / noticode serve -- no key. NotiCode is just the hands; the MCP client you connect brings the brain.
noticode chat / noticode telegram / noticode all -- needs ANTHROPIC_API_KEY, because here NotiCode calls the model itself.

Modes

Command	What it does	Needs key?
`all`	HTTP MCP + Telegram bot + scheduler, one process, shared agent.	Yes (for bot)
`mcp`	MCP server over stdio (connect Claude Desktop).	No
`serve`	MCP server over HTTP, prints a connectable URL.	No
`chat`	Interactive terminal agent.	Yes
`telegram`	Telegram bot only.	Yes

Quick start

git clone https://github.com/Antropov31/noticode-mcp.git
cd noticode-mcp
npm install
npx playwright install chromium   # only if you want the browser_* tools
npm run build
cp .env.example .env               # fill in keys you want to use

Then pick a mode, e.g. the full stack:

npm run all

Connect Claude Desktop (stdio)

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "noticode": {
      "command": "node",
      "args": ["/absolute/path/to/noticode-mcp/dist/index.js", "mcp"],
      "env": { "NOTICODE_WORKSPACE": "/absolute/path/to/your/project" }
    }
  }
}

Connect by URL (HTTP)

npm run serve (or all) prints something like http://127.0.0.1:4319/mcp. Paste it into any MCP client that supports the HTTP (Streamable HTTP) transport.

Create a bot with @BotFather, put the token in TELEGRAM_BOT_TOKEN.
(Recommended) Get your chat ID from @userinfobot and set TELEGRAM_CHAT_ID to lock the bot to just you.
npm run telegram (or npm run all). Text the bot. /start and /reset are supported.

Tools

Tool	What it does
`fs_read` / `fs_write` / `fs_edit`	Read, create/overwrite, exact-match edit files.
`fs_list` / `fs_search`	List dirs; glob + grep file contents.
`shell_exec`	Run any shell command on the host.
`sys_info`	OS, CPU, memory, user, workspace.
`tg_send` / `tg_send_photo` / `tg_read`	Message the user on Telegram (text/photo), read incoming messages.
`notify`	Send a task/event notification (via Telegram, or logged).
`ha_states` / `ha_call_service`	List Home Assistant entities; control devices and scenes.
`browser_navigate` / `browser_click` / `browser_type` / `browser_eval` / `browser_screenshot`	Drive a headless Playwright browser.
`screen_capture` / `webcam_capture`	Screenshot the desktop / snap a webcam photo (saved as PNG).
`schedule_add` / `schedule_list` / `schedule_cancel`	Cron jobs that run a command, an agent prompt, or a reminder.

Image tools save a PNG and return its path; send it on with tg_send_photo. All tools are defined once in src/tools/ and shared by every mode.

Scheduler

schedule_add takes a cron expression and a job type:

shell -- run a command; you get the output when it finishes.
prompt -- run an agent instruction (only in all/chat with an API key).
notify -- a plain reminder.

Results are pushed to you via Telegram when configured. Example: "every weekday at 9am, pull the repo and run tests" becomes a shell job on 0 9 * * 1-5.

Configuration

Env var	Default	Purpose
`ANTHROPIC_API_KEY`	--	Required for chat / telegram / all.
`NOTICODE_WORKSPACE`	`cwd`	Root directory the agent operates in.
`NOTICODE_HOST` / `NOTICODE_PORT`	`127.0.0.1` / `4319`	HTTP server bind.
`NOTICODE_TOKEN`	--	Optional bearer token for the HTTP endpoint.
`NOTICODE_ALLOWED_HOSTS`	--	Host-header allowlist for HTTP mode (DNS-rebinding protection). Empty = allow all.
`NOTICODE_ALLOWED_ORIGINS`	--	Origin allowlist for HTTP mode (browser clients). Requests without `Origin` always pass.
`NOTICODE_MAX_SESSIONS`	`32`	Max concurrent HTTP MCP sessions; new handshakes get `429` past the cap.
`NOTICODE_SESSION_TTL_MS`	`1800000`	Idle HTTP sessions older than this are closed and evicted.
`NOTICODE_MODEL`	`claude-sonnet-4-20250514`	Model for chat/telegram/all.
`NOTICODE_ALLOW_SHELL`	`true`	`false` to block shell execution.
`NOTICODE_ALLOW_WRITE`	`true`	`false` to make the agent read-only.
`NOTICODE_MAX_OUTPUT`	`30000`	Max chars returned per tool call.
`TELEGRAM_BOT_TOKEN`	--	Bot token from @BotFather.
`TELEGRAM_CHAT_ID`	--	Lock the bot to one chat; default notify target.
`HOME_ASSISTANT_URL`	--	Base URL of your Home Assistant.
`HOME_ASSISTANT_TOKEN`	--	Long-lived access token for Home Assistant.

Security

NotiCode runs arbitrary commands, edits files, drives a browser, sees your screen and camera, and can control your home. That power is the point and the risk. Scope NOTICODE_WORKSPACE tightly, flip NOTICODE_ALLOW_SHELL / NOTICODE_ALLOW_WRITE to false when you only need read access, keep the HTTP bind on 127.0.0.1 and set NOTICODE_TOKEN before tunneling, and always set TELEGRAM_CHAT_ID so a stranger who finds your bot can't drive your machine.

When you bind HTTP beyond localhost, also set NOTICODE_ALLOWED_HOSTS (Host-header allowlist against DNS rebinding) and NOTICODE_ALLOWED_ORIGINS (which browser origins may connect). NOTICODE_MAX_SESSIONS / NOTICODE_SESSION_TTL_MS bound resource usage per session.

Trust model: sandboxed files, privileged shell

fs_read / fs_write / fs_edit / fs_list / fs_search are sandboxed to NOTICODE_WORKSPACE (including symlink/junction escape checks). Paths outside the workspace are rejected with a Path must stay inside the workspace error — that rejection is the sandbox working, not a bug.
shell_exec is deliberately privileged: it starts in the workspace but, like a normal user terminal, can cd anywhere and run anything (including absolute paths and git commands outside the workspace). Treat shell access as full local-user access and gate it with NOTICODE_ALLOW_SHELL=false when you need a locked-down agent.

Project structure

src/
  index.ts              CLI entry (all | mcp | serve | chat | telegram | help)
  config.ts             Env-based configuration
  theme.ts              Blue terminal palette + banner
  runner/
    all.ts              Unified mode: HTTP MCP + Telegram bot + scheduler
  mcp/
    server.ts           buildMcpServer + stdio entry point
    http.ts             Streamable HTTP entry point (prints a URL)
  agent/
    core.ts             Shared agent loop (model + tool-use)
    agent.ts            Interactive terminal chat
    telegram-bot.ts     Telegram bot bridge to the agent loop
  scheduler/
    scheduler.ts        Cron scheduler runtime
  tools/
    index.ts            Tool registry
    types.ts            Shared tool + context types
    filesystem.ts       fs_read / fs_write / fs_edit / fs_list / fs_search
    shell.ts            shell_exec
    system.ts           sys_info
    telegram.ts         tg_send / tg_send_photo / tg_read
    notify.ts           notify
    home-assistant.ts   ha_states / ha_call_service
    browser.ts          browser_navigate / click / type / eval / screenshot
    capture.ts          screen_capture / webcam_capture
    scheduler.ts        schedule_add / schedule_list / schedule_cancel

Roadmap

HTTP / Streamable HTTP transport in addition to stdio
Telegram bot bridge
Unified all mode
Browser automation, screen/webcam capture, Home Assistant, scheduler
Streaming responses in chat mode
Pluggable LLM providers (OpenAI, local models)
Per-tool permission prompts
Git-aware diffs before writes

License

MIT © Antropov31

Available Tools

7 tools

fs_editC

Replace an exact substring in a file. old_string must match exactly once unless replace_all is true.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`new_string`	Yes
`old_string`	Yes
`replace_all`	No

TDQS

C2.9/5.0

Behavior2/5

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

The description implies mutation ('replace') but lacks disclosure of behavioral traits: no mention of file existence requirements, error behavior on no match or multiple matches (when replace_all=false), side effects, or permission needs. With no annotations, it is insufficient.

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?

Extremely concise: two sentences. The first sentence front-loads the purpose, the second adds a critical constraint. No wasted words.

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

Completeness2/5

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

Given the tool has 4 parameters, no output schema, and no annotations, the description covers only a fraction of necessary context. Important aspects like return value, error handling, and usage context are missing.

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

Parameters1/5

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

Schema coverage is 0%, yet the description only explains old_string and replace_all constraints. Path and new_string are left undefined; the agent must guess their formats and roles. This is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Replace an exact substring in a file') with a specific verb and resource, distinguishing it from siblings like fs_write (file overwrite) or fs_search (pattern search).

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?

No explicit guidance on when to use fs_edit versus other tools. The only usage hint is the constraint on old_string matching exactly once, but no context on prerequisites, error handling, or when to choose this tool over alternatives like fs_write for bulk operations.

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

fs_listA

List files and directories under a path, up to a given depth.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Directory to list (default: workspace root).
`depth`	No	How deep to recurse (default: 2).

TDQS

A3.7/5.0

Behavior3/5

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

No annotations supplied, so description must cover behavior. It implies a read-only, non-destructive operation but lacks details on hidden files, symlink handling, performance limits, or error cases. Adequate but not thorough.

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

Conciseness5/5

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

Single sentence of 13 words, no extraneous information. Ideal conciseness.

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?

Tool is simple with 2 optional parameters and no output schema. Description specifies main behavior but omits output format (e.g., full paths vs names, sorting), default depth, and whether hidden files are listed. Adequate for low 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 coverage is 100% with descriptions for both parameters. The description does not add meaning beyond the schema (e.g., format of path, recursion depth interpretation). Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'List' and resource 'files and directories'. Clearly distinguishes from siblings like fs_read (read file content) and fs_search (search for files). Scope 'under a path, up to a given depth' adds precision.

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?

No explicit when-to-use or when-not-to-use guidance. However, the tool's purpose is straightforward and alternatives are not critical. No exclusions or context provided.

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

fs_readA

Read a UTF-8 text file. Returns the full content, or a line range when start_line/end_line are given.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	File path, absolute or relative to the workspace.
`end_line`	No	1-based last line to return.
`start_line`	No	1-based first line to return.

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries burden. Describes reading UTF-8 text and returning full content or line range, but omits behavior on missing file, binary files, or large files.

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

Conciseness5/5

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

Two sentences, front-loaded with main purpose, no redundant information. Every sentence adds value.

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

Completeness4/5

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

Adequate for a simple read tool with 3 params and no output schema. Could mention that return is a string, but current description is sufficient.

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?

Schema coverage is 100%, baseline 3. Description adds context that without line params, full content is returned, clarifying parameter usage beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Read' and resource 'a UTF-8 text file', and indicates optional line range capability. Distinguishes from siblings like fs_write or fs_edit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Context for use is clear (reading file content), but no explicit when-not or alternative guidance provided beyond implicit differentiation from siblings.

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

fs_searchA

Find files by glob pattern. If query is set, also returns matching lines inside those files (grep-style).

ParametersJSON Schema

Name	Required	Description	Default
`glob`	No	Glob pattern, e.g. */.ts (default: everything).
`query`	No	Substring to search for inside matched files.

TDQS

A3.7/5.0

Behavior3/5

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

Discloses the conditional grep behavior when query is set, but does not mention default glob behavior, output format, or error cases. No annotations present, so description carries full burden.

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

Conciseness5/5

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

Single, clear sentence with no redundancy. Front-loads the main verb and resource.

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?

Explains core functionality and conditional behavior, but lacks detail on output format, search recursion, or performance. No output schema to compensate.

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

Parameters3/5

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

Schema covers both parameters with descriptions (100% coverage). Description adds conditional behavior context but minimal extra meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool finds files by glob pattern and optionally performs grep-style content search. Distinguishes from sibling tools like fs_list and fs_read.

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?

Implies use for file search with glob and optional content matching, but does not explicitly state when to use this tool vs alternatives like fs_list or fs_read. Lacks when-not-to-use guidance.

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

fs_writeA

Create or overwrite a file with the given content. Parent directories are created automatically.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`content`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses overwrite behavior and automatic directory creation, but lacks details on error handling, permissions, or idempotency. Adequate for a simple write operation.

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

Conciseness5/5

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

Single sentence that is front-loaded with key information. No wasted words; efficiently conveys core functionality.

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

Completeness4/5

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

Covers the main aspects: creation, overwriting, and directory creation. Missing details on encoding, size limits, or destructive nature, but acceptable for a basic file write tool.

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?

Adds meaning beyond the schema by explaining 'path' as file path and 'content' as file content. Compensates for 0% schema coverage by clarifying what the parameters represent.

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?

Description clearly states 'create or overwrite a file with given content' and mentions automatic parent directory creation. It is specific about the action and resource, but does not explicitly differentiate from sibling tools like fs_edit.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies replacement behavior but does not state when not to use it or suggest siblings.

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

shell_execA

Run a shell command on the host machine and return combined stdout/stderr. Full system access.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Working directory (default: workspace).
`command`	Yes	The shell command to execute.
`timeout_ms`	No	Kill the command after this many ms (default: 120000).

TDQS

A3.7/5.0

Behavior3/5

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

Without annotations, the description carries full burden. It discloses returning combined stdout/stderr and warns about full system access, but lacks details on error handling, blocking behavior, environment variables, or interactive commands. More transparency would be beneficial for a high-risk tool.

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

Conciseness5/5

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

The description is extremely concise (two sentences) and front-loaded with the core action. Every word adds value with no filler.

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 high risk and lack of output schema, the description is brief. It could include more about security implications, timeout behavior, and error handling. However, it adequately sets context for a shell execution tool among file-focused siblings.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning to the parameters beyond what the schema provides. No parameter-specific information is given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Run a shell command'), identifies the resource ('host machine'), and explains the output ('combined stdout/stderr'). It also clearly distinguishes from sibling tools (all file/system operations) by highlighting the shell execution capability.

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 shell commands but lacks explicit guidance on when to use vs. alternatives. The 'Full system access' warning hints at caution but does not provide explicit when-not-to-use scenarios or alternatives (though siblings are file-focused).

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

sys_infoA

Return host system information: OS, CPU, memory, user, and the active workspace.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description provides the return data categories but omits behavioral details like read-only nature, speed, or potential failure modes. It adequately indicates a read operation but could be more explicit.

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, front-loaded sentence with no unnecessary words. Every part contributes to the purpose.

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

Completeness5/5

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

Given zero parameters, no output schema, and simplicity, the description completely conveys what data is returned. No additional context is necessary.

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?

No parameters exist, and the description correctly adds no parameter info. The baseline of 4 applies as per guidelines for 0-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return' and the resource 'host system information' with specific categories (OS, CPU, memory, user, workspace). This distinguishes it from sibling tools which handle files or shell execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for retrieving system information, contrasting with file operations (fs_*) and shell commands (shell_exec). However, it lacks explicit 'when to use' or alternatives guidance.

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.

7 tool updatesv0.1.0Jun 25, 2026
- First observedfs_edit
- First observedfs_list
- First observedfs_read
- First observedfs_search
- First observedfs_write
- First observedshell_exec
- First observedsys_info

Deploy Server

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

TDQS

A3.8/5.0

Scored 2026-06-25 21:30 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: file operations (list, read, write, edit, search) are well-separated, while shell_exec handles arbitrary commands and sys_info provides system details. No overlap or ambiguity.

Naming Consistency5/5

Tool names follow a clear prefix convention: 'fs_' for file operations, 'shell_' for shell, 'sys_' for system. The naming is consistent and predictable, making it easy for an agent to infer functionality.

Tool Count5/5

With 7 tools, the server is well-scoped for file and system utilities. Each tool earns its place without being overwhelming or sparse.

Completeness4/5

The file operations cover list, read, write, edit, and search, but a delete operation is missing. While shell_exec can compensate, the dedicated file surface has a minor gap.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
237
KodyOAuth
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2653
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1

Related MCP Servers

file-system-mcp-server
File Systems Developer Tools
calebmwelsh
A
license
Not graded
quality
F
maintenance
A comprehensive MCP (Model Context Protocol) server for file system operations, providing Claude and other AI assistants with access to local files and directories.
Updated a year ago (2025-04-02 19:33 UTC)
2
MIT
vulcan-file-ops
File Systems Developer Tools Command Line
n0zer0d4y
A
license
A
quality
D
maintenance
MCP server that gives Claude Desktop and other desktop MCP clients filesystem powers—read, write, edit, and manage files like AI coding assistants.
Updated 4 months ago (2026-05-18 17:01 UTC)
17
27 npm
9
MIT
remote-mcp
File Systems Shell Access
longbiao7498
A
license
Not graded
quality
D
maintenance
A local MCP server that proxies file and shell tools (Read, Write, Edit, Bash, etc.) to a remote Linux host over SSH, enabling MCP clients like Claude Code to operate on remote codebases.
Updated 4 months ago (2026-05-31 23:18 UTC)
MIT
emcp
File Systems Shell Access Search
slezica
F
license
Not graded
quality
D
maintenance
MCP server providing filesystem operations, shell execution, and web search capabilities.
Updated a year ago (2025-10-12 19:35 UTC)
-

NotiCode

What is this?

The one-command setup: all

Do I need an API key?

Modes

Quick start

Connect Claude Desktop (stdio)

Connect by URL (HTTP)

Telegram

Tools

Scheduler

Configuration

Security

Trust model: sandboxed files, privileged shell

Project structure

Roadmap

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

The one-command setup: `all`