common_mcp
common_mcp
get_basic_details という1つのツールを公開するシンプルなMCPサービスです。
機能
stdio経由でMCPサーバーとして動作
単一のツール
get_basic_detailsを提供プラットフォーム、Nodeのバージョン、アーキテクチャ、現在時刻、稼働時間を返します
includeHostname: trueが指定された場合、オプションでホスト名を返します
Related MCP server: System Info MCP Server
セットアップ
npm install実行
npm startMCPクライアントの設定
クライアントがstdioサーバーを起動できるように、直接 node を使用してください。
Cursor
MCP設定(またはMCP設定ファイル)の下に以下を追加します:
{
"mcpServers": {
"common_mcp": {
"command": "node",
"args": [
"/Users/saurabhverma/Desktop/vibecoding/projects/common_mcp/server.js"
]
}
}
}Claude Desktop
~/Library/Application Support/Claude/claude_desktop_config.json に以下を記述します:
{
"mcpServers": {
"common_mcp": {
"command": "node",
"args": [
"/Users/saurabhverma/Desktop/vibecoding/projects/common_mcp/server.js"
]
}
}
}MCPツール呼び出しの例
ツール名: get_basic_details
入力:
{
"includeHostname": true
}署名
Saurabh Kumar
Available Tools
1 toolget_basic_detailsC
Returns basic system and runtime details.
| Name | Required | Description | Default |
|---|---|---|---|
| includeHostname | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It only says 'returns' but does not disclose read-only nature, side effects, or any potential costs. Minimal transparency.
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, very concise. But lacks structure; no additional details or sections. Adequate for a simple tool but not well-structured.
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 simplicity (1 optional param, no output schema), description should still explain what 'basic system and runtime details' includes and what the return looks like. Incomplete.
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 0% and description does not mention the 'includeHostname' parameter. No added meaning beyond what schema provides (which is just type boolean). Fails to compensate for low 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?
Description clearly states verb 'returns' and resource 'basic system and runtime details', which is a clear purpose. No siblings exist to differentiate, so no issue with distinction.
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. Since there are no siblings, some implied usage, but no explicit context or exclusions.
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.
1 tool update
v1.0.0- First observed
get_basic_details
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The single tool has a clear and distinct purpose.
There is only one tool, so naming consistency is not an issue. The name 'get_basic_details' follows a clear verb_noun pattern.
Having only one tool feels thin for a server labeled 'common_mcp'. While a single tool can be appropriate for very narrow scopes, this server's name suggests a broader utility, making the count borderline.
The server only provides basic system and runtime details. For a 'common' server, one would expect additional tools for other common operations, leaving significant gaps.
Maintenance
Related MCP Connectors
Generate IDs, QR codes, and hashes, encode values, geolocate IPs, plus gated host diagnostics.
Read-only developer, date, finance, and text utilities. Authless remote MCP server by Clean.tools.
Agent utility API: 28+ free endpoints (hash, QR, DNS, scrape, JWT...) run by an autonomous AI agent.
17 Base data tools for agents over Streamable HTTP MCP. Pay per call in USDC via x402; no API key.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables interaction with the local file system and retrieval of system information. Provides tools for listing directories, reading files, getting current time, and basic greeting functionality.-
- AlicenseNot gradedqualityDmaintenanceEnables comprehensive system monitoring and diagnostics through 18 tools that provide detailed information about CPU, memory, disk usage, network interfaces, running processes, battery status, hardware details, and temperature monitoring. Allows users to query system information and performance metrics through natural language interactions.7 npmISC
- AlicenseNot gradedqualityNot gradedmaintenanceEnables AI assistants to automatically identify which machine they're working with by providing hostname detection and system information including CPU, memory, OS version, and architecture.-
- AlicenseNot gradedqualityDmaintenanceA Node.js and TypeScript implementation that provides system information and health check tools for Claude Desktop. It serves as a boilerplate for building and integrating custom tools using the Model Context Protocol.3 npmISC