Which integrations are available for this server?

Integrates with Amazon Q CLI, allowing users to access and use tools from the MCP server through Amazon Q, with the tools being available under the 'mcp-server-scaffold___tool-name' namespace.

How do I use MCP Server Scaffold?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Server Scaffold echo back 'Hello, world!'" 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.

MCP Server Scaffold

by vjouenne76

Overview Schema Source Related Servers Discussions Admin

JavaScript

MCP Server Scaffold

A basic scaffolding project for building Model Context Protocol (MCP) servers.

What is MCP?

The Model Context Protocol (MCP) is an open protocol that standardizes how applications provide context to Large Language Models (LLMs). MCP enables secure, controlled interactions between AI systems and various data sources and tools.

Related MCP server: MCP Template

Features

This scaffold provides:

✅ Basic MCP server implementation
✅ Sample tools (echo, get_current_time)
✅ TypeScript support with proper types
✅ Error handling and logging
✅ Standard MCP protocol compliance
✅ Development and build scripts

Setup

Install dependencies:
```
npm install
```
Build the project:
```
npm run build
```
Start the server:
```
npm start
```

Development

For development with auto-rebuild and restart:

npm run dev

Available Tools

echo

Echoes back the provided message.

Parameters:

message (string, required): The message to echo back

get_current_time

Returns the current date and time in ISO format.

Parameters: None

Project Structure

mcp-server-scaffold/
├── src/
│   └── index.ts          # Main server implementation
├── dist/                 # Compiled JavaScript (generated)
├── package.json          # Project configuration
├── tsconfig.json         # TypeScript configuration
└── README.md            # This file

Extending the Server

To add new tools:

Add the tool definition in the ListToolsRequestSchema handler
Add the tool implementation in the CallToolRequestSchema handler
Rebuild and test

Example tool addition:

// In ListToolsRequestSchema handler
{
  name: 'my_new_tool',
  description: 'Description of what the tool does',
  inputSchema: {
    type: 'object',
    properties: {
      param1: {
        type: 'string',
        description: 'Description of parameter',
      },
    },
    required: ['param1'],
  },
}

// In CallToolRequestSchema handler
case 'my_new_tool':
  // Your tool implementation here
  return {
    content: [
      {
        type: 'text',
        text: `Result: ${args.param1}`,
      },
    ],
  };

Integration with Q CLI

To use this MCP server with Amazon Q CLI:

Build and ensure the server runs correctly
Configure the server in your Q CLI MCP settings
The tools will be available as mcp-server-scaffold___tool-name

Error Handling

The server includes comprehensive error handling:

Tool execution errors are caught and returned as error responses
Server errors are logged to stderr
Graceful shutdown on SIGINT

License

MIT License - feel free to use this scaffold as a starting point for your own MCP servers.

Available Tools

2 tools

echoB

Echo back the provided message

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	The message to echo back

TDQS

B3.1/5.0

Behavior2/5

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 'echoes back' the message, implying a simple read/return operation, but doesn't disclose any behavioral traits such as whether it modifies data, has side effects, requires authentication, or has rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and front-loaded with a single, clear sentence: 'Echo back the provided message.' There is zero waste, and every word earns its place by directly explaining the tool's function without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 simple parameter) and high schema coverage (100%), the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral aspects and return values, which could be helpful for an agent. It's complete enough for basic understanding but leaves gaps in operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'the provided message,' which aligns with the single parameter 'message' in the input schema. Since schema description coverage is 100% (the schema already describes 'message' as 'The message to echo back'), the description adds no additional meaning beyond what the schema provides. The baseline score of 3 is appropriate when the schema does the heavy lifting.

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?

The description clearly states the tool's function with a specific verb ('echo back') and resource ('the provided message'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (calculator, current_time), which are completely different functions, so it doesn't need sibling differentiation but could be more specific about what makes 'echo' unique in this context.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or comparisons with sibling tools like calculator or current_time, leaving the agent to infer usage based solely on the tool name and basic function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_timeB

Get the current date and time

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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 describes the action ('Get') but lacks details such as timezone handling, format of the returned date/time, whether it's real-time or cached, or any rate limits. This leaves significant gaps for an agent to understand how the tool behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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 for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks details on the return format (e.g., ISO string, timestamp) and behavioral aspects like timezone, which are important for completeness even in simple tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and it adds value by specifying what is retrieved ('current date and time'), which aligns well with the lack of inputs.

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?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current date and time'), making it immediately understandable. It doesn't distinguish from its sibling tool 'echo', but the purpose is unambiguous and not tautological with the name.

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?

The description provides no guidance on when to use this tool versus alternatives like 'echo' or other time-related tools that might exist. It states what it does but offers no context about appropriate use cases 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.

2 tool updatesAug 15, 2025
- First observedecho
- First observedget_current_time

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-04-18 09:25 across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: 'echo' handles message repetition while 'get_current_time' provides temporal information. There is no overlap in functionality, making it impossible to confuse them.

Naming Consistency3/5

The naming is mixed: 'echo' uses a simple verb form while 'get_current_time' follows a verb_noun pattern. Although both are readable, they lack a consistent convention, which could lead to unpredictability if more tools were added.

Tool Count2/5

With only 2 tools, this server feels thin for a 'scaffold' purpose, which typically implies a foundation for building more functionality. The count is too low to demonstrate meaningful coherence or coverage for most domains.

Completeness3/5

Given the vague 'scaffold' domain, it's hard to assess completeness, but the tools cover basic utility operations (echo and time). However, there are obvious gaps for a scaffold, such as file manipulation or configuration tools, limiting its usefulness as a foundation.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
Mercado PagoOAuth
com.mercadopago.mcp
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.
Finance E-commerce & Retail App Automation
2

Related MCP Servers

MCP Server Boilerplate
RAG Systems Agent Orchestration
cds-id
F
license
D
quality
D
maintenance
A ready-to-use starter implementation of the Model Context Protocol (MCP) server that enables applications to provide standardized context for LLMs with sample resources, tools, and prompts.
Updated 10 months ago (2025-11-08 04:58 UTC)
2
2 npm
1
-
MCP Template
Developer Tools
xcollantes
A
license
B
quality
D
maintenance
A template repository for building Model Context Protocol (MCP) servers that enable LLM clients to interact with custom tools and services through standardized JSON-RPC communication.
Updated 8 months ago (2026-01-11 08:02 UTC)
3
MIT
TypeScript MCP Server
Developer Tools Code Execution
chuljung
F
license
Not graded
quality
D
maintenance
A starter project designed to quickly build and deploy Model Context Protocol (MCP) servers using the TypeScript SDK and Zod for schema validation. It features example implementations for tools and resources, providing a solid foundation for custom MCP development and integration.
Updated 9 months ago (2025-12-15 08:24 UTC)
-
TypeScript MCP Server
Developer Tools Code Execution
opnthwrld
F
license
Not graded
quality
D
maintenance
A starter project designed to help developers quickly build and deploy Model Context Protocol servers using TypeScript and the official SDK. It includes example implementations of tools and resources, such as a calculator and greeting function, to provide a functional foundation for custom MCP development.
Updated 9 months ago (2025-12-16 01:00 UTC)
67 npm
-

MCP Server Scaffold

What is MCP?

Features

Setup

Development

Available Tools

echo

get_current_time

Project Structure

Extending the Server

Integration with Q CLI

Error Handling

License

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

MCP Server Boilerplate

MCP Template

TypeScript MCP Server

TypeScript MCP Server