Skip to main content
Glama
saurabh-sde3

common_mcp

by saurabh-sde3

common_mcp

Простой MCP-сервис, предоставляющий один инструмент: get_basic_details.

Что он делает

  • Работает как MCP-сервер через stdio

  • Предоставляет один инструмент: get_basic_details

  • Возвращает платформу, версию Node, архитектуру, текущее время и время работы системы

  • Опционально возвращает имя хоста, если includeHostname: true

Related MCP server: System Info MCP Server

Настройка

npm install

Запуск

npm start

Конфигурация MCP-клиента

Используйте node напрямую, чтобы клиент мог запустить stdio-сервер.

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 tool
get_basic_detailsC

Returns basic system and runtime details.

ParametersJSON Schema
NameRequiredDescriptionDefault
includeHostnameNo

TDQS

C2.4/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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. 1 tool updatev1.0.0
    • First observedget_basic_details

TDQS

C2.8/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. The single tool has a clear and distinct purpose.

Naming Consistency5/5

There is only one tool, so naming consistency is not an issue. The name 'get_basic_details' follows a clear verb_noun pattern.

Tool Count3/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables 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 npm
    ISC
  • A
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables 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.
    -
  • A
    license
    Not graded
    quality
    D
    maintenance
    A 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 npm
    ISC