Click on "Deploy 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., "@impossible-mcp what time is it on the server?"
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 TypeScript foundation for building Model Context Protocol servers that run locally over stdio or remotely over Streamable HTTP. Fork it, replace the example capabilities, and keep the operational pieces.
MCP tools, resources, prompts, and parameterized resources
stdio and Streamable HTTP transports from one server factory
health and readiness routes for HTTP deployments
validated environment configuration and structured logs
graceful process shutdown
strict TypeScript, tests, coverage gates, linting, formatting, and CI
Docker and Compose definitions
security, contribution, and release documentation
Related MCP server: template-mcp
npm install
cp .env.example .env
npm run devThe default transport is stdio. Run the HTTP service with:
MCP_TRANSPORT=http npm run devOn PowerShell:
$env:MCP_TRANSPORT = "http"
npm run devThe MCP endpoint is http://127.0.0.1:3333/mcp. Health checks are available at /healthz and /readyz.
Build the project and point an MCP host at the executable:
{
"mcpServers": {
"impossible-template": {
"command": "node",
"args": ["/absolute/path/to/impossible-mcp-template/dist/cli.js"]
}
}
}Start in src/server.ts. Replace the example echo and server-time tools, then update the resources and prompts. Keep application secrets in environment variables and add them to the logger's redaction paths.
The project separates transport wiring from capability registration. Tests can instantiate the server factory without opening a production port, and both transports expose the same behavior.
Command | Purpose |
| Run the server with file watching |
| Compile the production package |
| Run the test suite once |
| Enforce coverage thresholds |
| Check TypeScript and JavaScript rules |
| Check repository formatting |
| Run the complete local verification pipeline |
Return text to the caller with an optional prefix.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| prefix | No |
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 transparently states the behavior: returning text and optionally adding a prefix. It does not explicitly state that the operation is read-only or side-effect-free, but 'return' strongly implies it, which is adequate for this simple 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, front-loaded sentence with zero redundancy. It efficiently communicates the core action and the optional parameter.
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 only two simple parameters and no output schema, the description is nearly complete. It explains what the tool does and the role of the optional prefix. Minor ambiguity remains about the exact formatting of the prefix, but overall it gives an agent enough to use the tool 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 0%, so the description must compensate. It mentions that prefix is optional and implies it is prepended to text, providing meaning beyond the schema. However, it doesn't detail how the prefix is concatenated (e.g., spacing or order), which is left to the caller.
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 states a specific action: 'Return text to the caller' with an optional prefix. This clearly identifies the tool's function and distinguishes it from the sibling 'server-time' which is about time retrieval.
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?
Usage is implied by the description—if you need to echo text with an optional prefix, this is the tool. However, there is no explicit mention of alternatives, when not to use it, or comparison with sibling 'server-time', so it only meets the 'implied usage' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the server's current time as an ISO-8601 value.
| 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 the full behavioral burden. It accurately and simply conveys that this is a side-effect-free read returning a timestamp, and the ISO-8601 format specification adds useful precision. It does not state the timezone, but 'server's current time' is sufficiently explicit for a zero-parameter getter.
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?
One sentence with no filler. The action, target, and output format are all included without redundancy, which is ideal for such a minimal 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 stateless, parameterless read tool with no output schema, the description fully covers what an agent needs to know: what the tool returns and in what format. Nothing essential is missing.
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 zero parameters, so the baseline is 4. The description adds the ISO-8601 format detail, which is the only meaningful semantic context an agent needs beyond the empty 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?
The description clearly states the verb ('Return') and the exact resource ('the server's current time') plus the output format ('ISO-8601'). This unambiguously distinguishes it from the sibling echo, which would return input rather than a clock value.
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 gives no guidance on when to use this tool versus alternatives, and it does not mention the sibling echo or any exclusions. For a simple getter this is less critical, but the dimension asks for explicit context and none is provided.
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.
v0.1.0echoserver-timeScored across 2 tools
The two tools have completely distinct purposes: one echoes text, the other returns the server time. There is no possibility of an agent confusing them.
'echo' follows a verb style while 'server-time' uses a noun-phrase style with a hyphen, so the naming convention is not fully consistent. However, with only two tools, the mismatch is minor and both names are readable.
Two tools is on the thin side for a server, but the functionality is simple and each tool serves a clear standalone purpose. The count feels minimal rather than excessive.
The server has no clearly defined domain, so there are no obvious CRUD gaps. As a minimal utility set, echo and server-time cover their stated functions, but the surface is too sparse to call it complete for any broader purpose.
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
The official MCP Server for the Mux API
