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., "@MCP Stdio Server list the files in the src directory"
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 complete Model Context Protocol (MCP) server implementation using stdio transport that showcases:
Resources: File system access to read project files (README.md, package.json, src/server.ts)
Tools: Calculator for mathematical operations and file listing
Prompts: Code review and code explanation assistants
MCP server with stdio transport
File reading resources for project files
Mathematical calculator tool
Directory listing tool
Code review and explanation prompt templates
VSCode integration ready
Test client for basic functionality testing
Related MCP server: MCP Server Demo
Install dependencies:
npm installBuild the project:
npm run buildnpm run test-simpleThis runs a simple client that tests basic MCP communication with the server.
First, install mcp-cli globally:
npm install -g @modelcontextprotocol/cliThen run comprehensive tests:
# Set the MCP configuration
export MCP_CLI_CONFIG_PATH=$(pwd)/mcp_config.json
# On Windows Command Prompt, use: set MCP_CLI_CONFIG_PATH=%cd%\mcp_config.json
# List available tools
mcp-cli tool list --server hjmcp-stdio
# Test calculator tool
mcp-cli tool call calculate --server hjmcp-stdio --input '{"expression": "2 + 3 * 4"}'
# Test file listing tool
mcp-cli tool call list_files --server hjmcp-stdio --input '{"directory": "."}'
# Test resource reading
mcp-cli tool read file://package.json --server hjmcp-stdioVSCode has built-in MCP support and connects directly to your server. You do NOT need to install mcp-cli for VSCode integration.
Add this to your VSCode MCP settings to use this server:
{
"mcpServers": {
"hjmcp-stdio": {
"command": "node",
"args": ["dist/server.js"],
"cwd": "/absolute/path/to/your/hjmcpstdio/directory",
"transport": "stdio"
}
}
}Important Notes:
Replace /absolute/path/to/your/hjmcpstdio/directory with the actual absolute path to this project directory
Make sure you've run npm run build first to compile the TypeScript
VSCode will handle all MCP communication automatically - no additional tools needed
npm run build - Compile TypeScript to JavaScript
npm run dev - Watch mode compilation
npm run start - Run the MCP server directly
npm run test-simple - Run basic client test
npm run clean - Remove build files
file://README.md - Project documentation
file://package.json - Package configuration
file://src/server.ts - Server source code
calculate - Perform mathematical calculations
Input: {"expression": "mathematical expression"}
Example: {"expression": "2 + 3 * 4"}
list_files - List files in a directory
Input: {"directory": "relative path"} (optional, defaults to ".")
Example: {"directory": "src"}
code-review - Get code review suggestions
Arguments: file_path (required), focus_areas (optional)
explain-code - Get code explanations
Arguments: code_snippet (required), language (optional)
src/server.ts - Main MCP server implementation
src/simple-client.ts - Basic test client
mcp_config.json - MCP CLI configuration for testing
package.json - Project configuration and dependencies
tsconfig.json - TypeScript configuration
Quick Testing (No Additional Setup):
Use npm run test-simple for basic functionality verification
Comprehensive Testing (Requires mcp-cli):
Install mcp-cli globally: npm install -g @modelcontextprotocol/cli
Use mcp-cli commands for detailed tool and resource testing
VSCode Integration (No mcp-cli Needed):
Add server configuration to VSCode MCP settings
VSCode handles MCP communication automatically
The server has been tested with:
✅ Tool functionality (calculate, list_files)
✅ Resource reading (package.json confirmed working)
✅ Stdio transport communication
✅ MCP protocol compliance
✅ Cross-platform compatibility (Windows, macOS, Linux)
Perform mathematical calculations
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | Mathematical expression to evaluate (e.g., '2 + 3 * 4') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'perform' but doesn't disclose behavioral traits like error handling, precision, supported operations, or output format. It's minimal and lacks necessary context for a tool with no 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, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain return values, error cases, or behavioral context, leaving significant gaps for a tool that performs calculations.
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 schema already documents the 'expression' parameter. The description adds no meaning beyond what the schema provides, such as examples of complex expressions or limitations. Baseline 3 is appropriate when schema does the heavy lifting.
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 'Perform mathematical calculations' states a general purpose but lacks specificity about what kind of calculations or resources are involved. It doesn't distinguish from the sibling 'list_files', but it's not tautological with the name 'calculate'.
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 provides no guidance on when to use this tool versus alternatives or any contextual prerequisites. It's a standalone statement with no implied usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files in the project directory
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | Directory path relative to project root (default: '.') | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention any constraints like permissions, rate limits, pagination, or what happens with invalid paths. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 wasted words. It's front-loaded with the core purpose, making it highly efficient and easy to parse.
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 no annotations and no output schema, the description is incomplete for a tool that likely returns a list of files. It doesn't explain the return format, error conditions, or behavioral details, leaving the agent with insufficient context for reliable 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?
Schema description coverage is 100%, with the parameter 'directory' fully documented in the schema. The description doesn't add any meaning beyond the schema, but the baseline is 3 when schema coverage is high, as the schema already provides adequate parameter 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 clearly states the verb ('List') and resource ('files in the project directory'), making the purpose immediately understandable. It doesn't distinguish from the sibling tool 'calculate', but that's a different function, so the lack of explicit differentiation doesn't significantly harm clarity.
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 or in what context it's appropriate. The description only states what it does, not when or why to invoke it, leaving the agent without usage context.
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.0.0calculatelist_filesThe two tools have completely distinct purposes: 'calculate' handles mathematical operations, while 'list_files' deals with file system navigation. There is no overlap or ambiguity between these functions, making tool selection straightforward for an agent.
The naming is mixed: 'calculate' uses a verb-only format, while 'list_files' follows a verb_noun pattern. Although both are readable, the inconsistency in naming conventions (one tool lacking an object) prevents a higher score for consistency.
With only two tools, the server feels thin and under-scoped for a 'Stdio Server' which typically implies broader utility or system operations. This minimal set may limit agent capabilities in handling diverse tasks, suggesting an incomplete or overly narrow implementation.
Given the server name 'MCP Stdio Server', which implies standard input/output or general system utilities, the toolset is severely incomplete. It lacks essential operations like reading/writing files, executing commands, or managing processes, creating significant gaps that will hinder agent workflows.
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…
A Model Context Protocol server for Wix AI tools
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.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hotjoebq/hjmcpstdio'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
