The my-mcp-server is a Node.js server implementing the Model Context Protocol (MCP) that provides three tools for AI-powered interactions:
Greet: Generate personalized greeting messages by providing a name
Calculate: Evaluate basic mathematical expressions (e.g., 2 + 2)
Weather Info: Retrieve mock weather data for a specified city
Enables access to a GitHub repository containing the MCP server implementation, allowing users to clone the project and use the provided tools.
Provides a simple MCP server implementation in Node.js with three tools: greet for personalized messages, calculate for basic math operations, and weather_info for retrieving mock weather data for cities.
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., "@my-mcp-server what's the weather in Tokyo?"
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 simple Model Context Protocol (MCP) server implementation in Node.js. This server exposes three tools via MCP:
greet: Greet someone with a personalized message.
calculate: Perform basic math calculations.
weather_info: Get mock weather information for a city.
Above ones are implemented in the server1.js
in server2 there is an agent that requires selenium web driver that launches the html provided in prompt in a browser and tests and returns if any console errors are thrown.
All these agents can be used in not just copilot but with other AI extensions too for example refer this video for Amazon Q --> https://www.youtube.com/watch?v=sF6KkaV102M
MCP server using @modelcontextprotocol/sdk
Stdio transport for easy integration
Extensible tool definitions
Related MCP server: HelloWorld MCP Server
Clone the repo and install dependencies
git clone https://github.com/devashish234073/my-mcps
cd my-mcps
npm installOpen the my-mcp folder in vscode
Open copilot chat
In the chat click on "Configure Tools"
Add more tools
Add MCP Server
This creates an mcp.json file with minimal configuration of the command your mcp server will run, in our case the repo already has that so step #4 to #7 is not needed
Just go to that file and click "Restart"
The server.js has three tools greet, calculate and weather_info
You can interact with these now using prompts like:
Perform basic math calculations
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | Math expression to evaluate (e.g., '2 + 2') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'perform basic math calculations' but doesn't disclose behavioral traits like error handling, supported operations, precision limits, or output format. This leaves significant gaps for an agent to understand how the tool behaves beyond its basic purpose.
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 wasted words. It's appropriately sized for a simple tool and front-loads the core purpose without unnecessary elaboration.
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 complexity (low), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'basic math' includes, how results are returned, or any limitations. For a tool with no structured behavioral data, the description should provide more context to be fully 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 description coverage is 100%, with the parameter 'expression' well-documented in the schema as 'Math expression to evaluate (e.g., '2 + 2')'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high 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's purpose with a specific verb ('perform') and resource ('basic math calculations'), making it immediately understandable. It doesn't differentiate from sibling tools (greet, weather_info), but those are unrelated domains, so differentiation isn't needed here.
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. It doesn't mention any prerequisites, limitations, or scenarios where other tools might be more appropriate. The sibling tools are unrelated, so no explicit comparison is needed, but general usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Greet someone with a personalized message
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the person to greet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool creates a personalized message but doesn't disclose behavioral traits like whether it's read-only, requires authentication, has side effects, or details about the output format. This leaves significant gaps for an agent to understand the tool's behavior.
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 that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects, output format, and usage context. For a tool with one parameter, it should provide more guidance on how the greeting is generated or what the result looks like.
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 input schema has 100% description coverage, with the 'name' parameter clearly documented. The description adds no additional meaning beyond the schema, as it doesn't explain parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the 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 clearly states the tool's purpose with a specific verb ('greet') and resource ('someone'), specifying it creates a personalized message. However, it doesn't differentiate from sibling tools like 'calculate' or 'weather_info', which are unrelated, so no sibling distinction is needed but could be mentioned for completeness.
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. It doesn't mention any context, prerequisites, or exclusions, such as when to choose 'greet' over other communication tools or in what scenarios it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather information for a city
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | The city name |
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 the tool 'Get weather information for a city', which implies a read-only operation, but does not specify details like error handling, rate limits, authentication needs, or what happens if the city is invalid. This leaves significant gaps in understanding the tool's behavior.
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 that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent 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 the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format, which are important for a tool with no annotations or output schema to guide the agent.
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 input schema has 100% description coverage, with the 'city' parameter clearly documented as 'The city name'. The description does not add any additional meaning beyond this, such as format examples or constraints, so it meets the baseline score of 3 where the 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 clearly states the tool's purpose with a specific verb ('Get') and resource ('weather information for a city'), making it immediately understandable. However, it does not distinguish this tool from potential siblings (like 'calculate' or 'greet'), which would require explicit differentiation to earn a perfect score.
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, such as the sibling tools 'calculate' or 'greet'. It lacks any context about prerequisites, exclusions, or specific scenarios, leaving the agent to infer usage based solely on the tool name and description.
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.0calculategreetweather_infoEach tool has a clearly distinct and non-overlapping purpose: calculate handles math, greet handles messaging, and weather_info handles weather data. An agent can easily tell them apart with no risk of misselection.
The naming is mixed: calculate and greet are verbs, while weather_info is a noun phrase. There is no consistent verb_noun pattern, but the names are still readable and descriptive.
With only 3 tools, the server feels thin and under-scoped for a general-purpose MCP server. The tools cover unrelated domains (math, greeting, weather), suggesting a lack of cohesive focus.
The server lacks a clear domain, making completeness hard to assess. Each tool stands alone without supporting operations (e.g., no update or delete for weather), leading to significant gaps in any potential workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
POC MCP server. Tool say_hello returns 'Welcome' (agent -> MCP -> API path).
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/devashish234073/my-mcps'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
