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., "@omni-mcp-server search GitHub for MCP servers and save the top result to memory"
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.
One MCP server instead of six. GitHub, local Git, Slack, web fetching, persistent memory, and filesystem tools — 15 tools in a single config entry, with dangerous capabilities off by default.
Setting up MCP usually means installing and configuring a separate server for every capability — one for GitHub, one for filesystem, one for memory, one for fetch. Each has its own config block, its own runtime, its own startup cost.
Omni bundles the everyday developer tools into one server, one config entry, one npx command:
You'd normally install… | With Omni |
| ✅ built in |
| ✅ built in |
| ✅ built in |
| ✅ built in |
a git server | ✅ built in |
a Slack server | ✅ built in |
🔒 Safe by default — shell execution and file writes are disabled unless you explicitly opt in to Agent Mode.
🏠 Local & private — runs on your machine over stdio. You bring your own tokens; nothing is proxied through a third party.
🪶 Zero install — runs straight from npm via npx.
Related MCP server: Modular MCP Server
npx -y @bitofacoder/omni-mcp-server@latest setupThe wizard asks for your optional tokens (GitHub, Slack), asks whether to enable Agent Mode, and updates your Claude Desktop config for you. Restart Claude Desktop and you're done.
claude mcp add omni -e GITHUB_PERSONAL_ACCESS_TOKEN=your_gh_token -- npx -y @bitofacoder/omni-mcp-server@latestAdd this to your client's MCP config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"omni": {
"command": "npx",
"args": ["-y", "@bitofacoder/omni-mcp-server@latest"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "your_gh_token",
"SLACK_BOT_TOKEN": "your_slack_token"
}
}
}
}All env vars are optional — tools that need a missing token simply tell you so.
Group | Tool | What it does |
🐙 GitHub |
| Search GitHub repositories |
| Get details of a specific issue | |
🌳 Local Git |
| Working tree + staging area status |
| View local code changes | |
| View commit history | |
| Commit staged changes with a message | |
💻 System |
| Read a local file |
| List a directory | |
| ⚠️ Write a file (Agent Mode only) | |
| ⚠️ Run a shell command (Agent Mode only) | |
🌐 Web |
| Fetch any public URL as clean Markdown — no API key needed |
🧠 Memory |
| Save a note/preference across chats |
| Retrieve a saved memory | |
| List everything remembered | |
💬 Slack |
| Send a message to a Slack channel |
system_execute_command and system_write_file let the AI act on your machine — run tests, install packages, edit files. Because that's real power, they are disabled by default and don't even appear in the tool list until you enable them:
"env": {
"OMNI_AGENT_MODE": "true"
}Everything else (reading files, git status, web fetch, memory) is read-only or sandboxed to its own data file.
PRs welcome — especially new integrations (Linear, Notion, Jira, Discord) and Agent Mode hardening (allowlists, working-dir scoping). Open an issue first for bigger changes.
If Omni saved you some config wrangling, a ⭐ helps other people find it.
MIT — see LICENSE.
Commit currently staged changes with a specific message.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The commit message. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full behavioral burden. It correctly indicates this is a mutation (committing changes), but does not disclose what happens if no staged changes or other edge cases. Adequate but not comprehensive.
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 with no redundant information. It is concise and directly states the tool's purpose.
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 mutation with one required parameter and no output schema, the description covers the essential behavior. However, it could mention error conditions (e.g., no staged changes) for 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?
Schema description coverage is 100% for the single required parameter. The description adds minimal extra meaning ('specific message' is implicit from the schema). 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 action ('commit'), the resource ('currently staged changes'), and the required input ('specific message'). It effectively distinguishes from sibling tools like git_status, git_diff, and git_log.
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 use when staged changes exist, but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites (e.g., staged changes required) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run git diff to see exact line-by-line code changes. Shows unstaged changes by default.
| Name | Required | Description | Default |
|---|---|---|---|
| staged | No | If true, runs git diff --staged to see staged changes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It states the default mode but fails to disclose that it is a read-only operation, what the output format is, or any potential side effects (e.g., large diffs).
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?
Two sentences, no wasted words. The first sentence defines the core purpose, and the second clarifies the default behavior. Ideal for a simple tool.
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 one boolean parameter and no output schema, the description adequately covers what the tool does and its default behavior. It lacks details about output format but this is standard git knowledge. Overall sufficient.
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 covers the single parameter (staged) with a description. The tool's description reiterates the default (unstaged) and implies the parameter's effect, but adds no additional meaning beyond the schema. Baseline 3 is appropriate given 100% schema coverage.
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 runs 'git diff' to show 'exact line-by-line code changes', which is specific and distinguishes it from sibling tools like git_status (summary) and git_log (history).
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 notes the default behavior (unstaged changes) and the staged parameter, but provides no guidance on when to use this tool versus alternatives like git_status or git_log, nor mentions any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific GitHub issue
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | ||
| owner | Yes | ||
| issue_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It does not disclose any behavioral traits beyond 'get details'. No mention of read-only nature, authorization needs, rate limits, or response structure. This is insufficient for a tool with zero annotations.
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, clear sentence with no unnecessary words. It is minimal and to the point, earning a top score for 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?
Given the tool has no output schema and no annotations, the description provides the core purpose but omits context like return value structure, error handling, or usage prerequisites. This is borderline adequate for such a simple tool but could be improved.
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 0%, but the parameter names ('owner', 'repo', 'issue_number') are self-explanatory, reducing the need for extensive documentation. The description adds no parameter information, but the schema is clear enough for a simple 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 uses a specific verb ('Get details') and a clear resource ('a specific GitHub issue'), making the tool's purpose immediately obvious. No ambiguity and distinguishes from all siblings that deal with different domains (search, messaging, files, etc.).
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 explicit guidance is provided on when to use this tool versus alternatives. The description lacks exclusions or comparison to other tools. However, given that no sibling tool directly overlaps with retrieving issue details, the need for such guidance is reduced, making it minimally viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for GitHub repositories
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query (e.g., "language:typescript stars:>1000") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as pagination, rate limits, or authentication requirements, which are critical for a search 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 is a single, clear sentence without unnecessary words, but could benefit from slightly more detail without becoming 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?
Given the simplicity of the tool (single parameter, no output schema), the description is minimal but omits important context like return format, pagination, or sorting options.
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% and the schema includes a descriptive example for the query parameter. The description adds no additional meaning beyond what the schema provides, 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 the verb 'search' and resource 'GitHub repositories', distinguishing it from siblings like github_get_issue which deals with a single issue.
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, no prerequisites or exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run git log to see recent commit history.
| Name | Required | Description | Default |
|---|---|---|---|
| maxCount | No | Maximum number of commits to show (defaults to 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose side effects, safety profile, or error behavior; merely states the action.
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, efficient and front-loaded, but could include more context without becoming 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?
Acceptable for a simple tool with one parameter, but lacks information about output format or behavior for edge cases.
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 covers the only parameter with clear description; tool description adds no extra 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?
Clearly states verb 'Run git log' and resource 'commit history', distinguishing from sibling tools like git_status and git_diff.
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; no context provided about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run git status to see the state of the working directory and staging area.
| 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 carries full burden. It describes running git status, a read-only operation, but does not explicitly state it is non-destructive or discuss potential side effects, performance, or prerequisites.
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, front-loaded sentence that efficiently communicates the tool's action and target, with no unnecessary 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?
For a simple tool with no parameters and no output schema, the description provides enough context for an agent to understand the tool's purpose. It could mention the output format or similarity to the git status command, but is otherwise adequate.
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, so schema coverage is 100%. The description adds value by stating the tool's purpose beyond the empty schema, making it clear what the tool does without needing parameter details.
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 'Run git status' and the resource 'working directory and staging area', providing a specific purpose that distinguishes it from sibling tools like git_diff and git_commit.
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 use for inspecting the current state but does not explicitly state when to use it versus alternatives like git_diff or git_log, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all the memory keys currently saved in persistent storage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the action and resource but omits details like order, performance implications, or whether it retrieves keys or key-value pairs. A 3 is appropriate for a simple, no-parameter tool, but additional context would improve safety.
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, no superfluous words. Clearly communicates the tool's purpose without redundancy. Efficiently structured for quick comprehension.
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 (no parameters, no output schema, no annotations), the description provides sufficient context: it lists all memory keys from persistent storage. No additional details are necessary for correct invocation.
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?
There are no parameters (100% schema coverage), so the description need not add parameter details. Baseline 4 applies, as the description does not need to compensate for any missing schema information.
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 uses a specific verb ('List') and resource ('all the memory keys'), clearly indicating the tool's function. It distinguishes itself from siblings like memory_store and memory_retrieve by specifying the listing action and persistent storage context.
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 is provided on when to use this tool over alternatives (e.g., memory_retrieve for a specific key, memory_store for writing). There is no explicit 'when-not' or mention of alternative tools, leaving the agent to infer from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a previously saved memory by its key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The unique key of the memory to retrieve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain behavior fully, but it only states the basic action. It does not mention what happens if the key does not exist, permissions required, or whether retrieval is read-only.
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, clear sentence with no unnecessary words or 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 retrieval tool with one required parameter and no output schema, the description is minimally complete. However, it could mention the return format or typical usage to be more helpful.
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% and the parameter 'key' is clearly described in the schema. The description adds no additional semantic detail, so a 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 verb (Retrieve) and resource (memory by key), and it distinguishes from siblings like memory_store and memory_list, which have different operations.
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 memory_list or memory_store. The agent is given no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a note, preference, or piece of context to persistent memory so it can be recalled in future conversations.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | A unique, descriptive identifier for this memory (e.g., "user_project_goals", "react_preferences"). Keep it snake_case. | |
| content | Yes | The detailed content you want to remember. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully cover behavioral traits. It mentions 'persistent memory' but omits details like overwrite behavior, size limits, or data retention, which are important for an agent to anticipate 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?
Single, well-formed sentence that directly conveys the tool's purpose. No fluff or unnecessary 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?
For a simple tool with 2 parameters and no output schema, the description is adequate but lacks behavioral context (e.g., overwrite rules). Could be more informative given the absence of annotations.
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 baseline is 3. The description adds a hint about snake_case key naming but otherwise repeats schema info. No extra meaning for content parameter beyond 'detailed content'.
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 saves notes, preferences, or context to persistent memory, which is a specific write operation. It distinguishes itself from siblings like memory_retrieve (read) and memory_list (list).
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 explicit instructions on when to use this tool vs. alternatives (e.g., system file write). The description implies use for persisting context, but lacks when-not or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to a Slack channel
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The message text to send | |
| channel | Yes | The channel ID or name (e.g., "#general") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It fails to mention important traits such as whether markdown is supported, behavior if the channel does not exist, authentication requirements, or rate limits, leaving significant gaps for an agent.
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 extremely concise with a single sentence that contains no fluff. It is front-loaded with the essential information, and every word earns its place.
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 two-parameter tool with no output schema or annotations, the description is minimal but covers the basic purpose. However, it lacks behavioral context (e.g., error handling, formatting support), which would be expected for safe agent usage.
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 input schema already describes both parameters adequately. The description adds no additional meaning beyond the schema, earning the baseline score of 3.
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 'Send' and the resource 'a message to a Slack channel', making the tool's purpose immediately obvious. It is distinct from all sibling tools, which are unrelated to messaging.
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 explicit guidance on when to use this tool versus alternatives. However, since no other messaging sibling exists, usage is implied. A higher score would require context on edge cases or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List contents of a local directory
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states the basic action. It does not disclose behavior on errors, recursion, or output format, leaving the agent with minimal insight.
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?
A single sentence that is efficient and front-loaded. However, it is slightly too brief for a tool with no annotations or output schema.
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 no output schema and no details on listing format or recursion, the description is adequate for a basic directory listing but lacks completeness for nuanced use.
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 sole parameter 'path' is fully described in the schema (100% coverage). The description adds no extra meaning beyond the schema definition, 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 'List contents of a local directory' uses a specific verb ('List') and resource ('contents of a local directory'), clearly distinguishing it from siblings like system_read_file or github_search_repos.
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 is provided on when to use this tool versus alternatives, nor are there any exclusions or context hints. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a local file from the system
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not discuss behavior like file permissions, error handling, encoding, or return format. This is a significant gap for a file read operation.
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 wasted words. However, it could benefit from structure (e.g., bullet points) to improve scanability.
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 (1 param, no output schema), the description lacks essential details like return value (file content) and potential side effects. The agent lacks sufficient information to invoke correctly.
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% (path parameter is described). The tool description adds no additional meaning beyond what the schema provides, 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 uses a specific verb 'Read' and resource 'a local file', clearly indicating the tool's action. It distinguishes from sibling like system_list_dir which lists directory contents.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exceptions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public web page and read its content as clean Markdown
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full URL of the web page to fetch (e.g., https://example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It specifies 'public' indicating no authentication, and 'clean Markdown' hinting at output transformation. However, it omits details about rate limits, page size limits, or error handling, which are relevant for a fetch 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 is a single sentence with no unnecessary words. It is front-loaded with the action and resource, achieving conciseness without sacrificing clarity.
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 low complexity (one parameter, no output schema, no nested objects), the description is nearly complete. It clearly states the input and output format. It could mention that the output is plain Markdown text or note any limitations, but it suffices for a straightforward fetch operation.
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 description adds context that the URL is for a public page and the output is Markdown, but does not add additional parameter semantics beyond what the schema already provides.
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 'Fetch' and the resource 'a public web page', with the specific outcome 'read its content as clean Markdown'. It uniquely distinguishes this tool from its siblings, none of which are web fetching tools.
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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or limitations (e.g., only public pages). The description implies its use case but does not explicitly state context or exclusions.
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. Dates show when Glama detected each change.
v1.1.1git_commitgit_diffgit_loggit_statusgithub_get_issuegithub_search_reposmemory_listmemory_retrievememory_storeslack_send_messagesystem_list_dirsystem_read_fileweb_fetchEach tool has a unique domain prefix (github_, slack_, system_, web_, memory_, git_) and a distinct action, making it clear which tool to use for a given task. There is no overlap in functionality between tools from different domains.
Most tools follow a <domain>_<verb> or <domain>_<verb>_<object> pattern (e.g., github_search_repos, slack_send_message), but git tools use nouns (git_status, git_diff, git_log) instead of verbs, breaking the consistency. Memory tools also use verbs without objects (memory_store) rather than verb_noun.
With 13 tools covering 6 different domains, the count is reasonable for an omnibus server. It provides a focused set of utilities without overwhelming the user, though some domains could benefit from a few more tools.
Each domain has significant gaps: GitHub only offers search and get issue (no create/update/delete), Slack only send message (no read/list), system only read and list dir (no write/delete), and git lacks add, push, pull, and branch operations. This can cause agent failures when users request common operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
An MCP server that gives your AI access to the source code and docs of all public github repos
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitofacoder/omni-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
