Skip to main content
Glama
enesjakozh
stevennevins

MCP Server Template

by stevennevins
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

MCP Server Template

Prerequisites

LLM CLI Installation

This project requires the LLM CLI to be installed. You can install it using Homebrew:

brew install llm

After installation, ensure the llm command is available in your PATH by running:

llm --version

Related MCP server: MCP Server Template

Getting Started

Development

  1. Install dependencies:

    npm install

  2. Start the development server with hot reload:

    npm run dev

  3. Build the project:

    npm run build

  4. Run tests:

    npm test

  5. Start the production server:

    npm start

Architect Tool

The Architect tool (src/tools/architect.ts) provides an interface to interact with the LLM CLI for architectural design feedback. It maintains conversation context and handles the communication between your application and the LLM CLI.

Features

  • Maintains conversation context across multiple interactions

  • Handles command execution through the LLM CLI

  • Provides error handling and logging

  • Supports both new conversations and continued discussions

Requirements

  • The LLM CLI must be installed and available in your PATH (see Prerequisites section)

  • Environment variables should be properly configured for the LLM CLI

Testing

The template includes a built-in TestClient for local testing and the MCP Inspector for visual debugging.

Using TestClient

The TestClient provides a simple way to test your tools:

import { TestClient } from "./utils/TestClient";

describe("YourTool", () => {
  const client = new TestClient();

  it("should process data correctly", async () => {
    await client.assertToolCall(
      "your-tool-name",
      { input: "test" },
      (result) => {
        expect(result.toolResult.content).toBeDefined();
      }
    );
  });
});

Using MCP Inspector

The template includes the MCP Inspector for visual debugging of your tools:

  1. Start the inspector:

    npx @modelcontextprotocol/inspector node dist/index.js

  2. Open the inspector UI at http://localhost:5173

The inspector provides:

  • Visual interface for testing tools

  • Real-time request/response monitoring

  • Tool metadata inspection

  • Interactive testing environment

Local Testing with Cursor

To test your MCP server locally with Cursor:

  1. Build and link the package:

    npm run build
npm run link

  2. Verify the binary works:

    npx architect-test-mcp-tool

  3. Add the server to Cursor:

    • Open Cursor settings

    • Navigate to the Features tab

    • Scroll down to MCP Servers section

    • Click "Add Server"

    • Select "Command" type

    • Give it a name (e.g., "Local Example Tool")

    • Enter the command: npx architect-test-mcp-tool

    • Click Confirm

  4. Verify the server starts correctly in Cursor by checking the MCP Servers section shows your server as running.

Note: If you make changes to your code, remember to rebuild and relink:

npm run build
npm run link

When you're done testing, you can unlink the package:

npm run unlink

This will remove the global symlink created during development.

Troubleshooting

Using MCP Inspector

The MCP Inspector is a helpful tool for debugging and inspecting your MCP server. To use it:

  1. First, build your project:

    npm run build

  2. Run the inspector:

    npx @modelcontextprotocol/inspector node dist/index.js

The inspector provides a web interface that allows you to:

  • View all available tools and their schemas

  • Test tool calls interactively

  • Inspect request/response payloads

  • Debug communication issues between your server and clients

Available Tools

1 tool
architectC

MCP server for the LLM Architect tool. Exposes resource "/llm-architect/chat" accepting POST requests with a prompt and optional conversationId, and interacts with the llm chat CLI to provide architectural design feedback while maintaining conversation context.

ParametersJSON Schema
NameRequiredDescriptionDefault
conversationIdNoOptional conversation ID for context
inputYesInput prompt to process

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'interacts with the llm chat CLI to provide architectural design feedback while maintaining conversation context,' which implies it's a read/write operation with state persistence. However, it lacks details on authentication needs, rate limits, error handling, or what specific 'architectural design feedback' entails. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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

Conciseness4/5

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

The description is appropriately sized and front-loaded, starting with the tool's role as an MCP server and its key functionality. It uses two sentences efficiently: the first covers the resource and parameters, and the second explains the interaction with the CLI and purpose. There's minimal waste, though it could be slightly more concise by integrating the two ideas more tightly.

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 complexity (a chat-based tool with conversation context), no annotations, and no output schema, the description is moderately complete. It explains the tool's purpose and parameters but lacks details on behavioral traits like response format, error cases, or specific feedback mechanisms. For a tool without structured output information, it should do more to compensate, but it provides a basic viable understanding.

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 adds some semantic context beyond the input schema. It mentions that the tool accepts 'a prompt and optional conversationId,' which aligns with the schema's 'input' (required) and 'conversationId' (optional) parameters. However, with 100% schema description coverage (both parameters have descriptions in the schema), the description doesn't provide additional meaning or usage examples. This 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.

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: it's an MCP server that exposes a resource for POST requests to interact with an LLM chat CLI for architectural design feedback. It specifies the verb ('interacts with'), resource ('/llm-architect/chat'), and context ('maintaining conversation context'). However, since there are no sibling tools mentioned, it doesn't need to distinguish from alternatives, so it falls just short of 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal usage guidance. It mentions that the tool accepts POST requests with a prompt and optional conversationId, but it doesn't explain when to use this tool versus other potential tools (though none are listed as siblings), nor does it provide context about when this specific architectural feedback tool is appropriate versus general chat tools. No exclusions or alternatives are mentioned.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'architect' has a clearly defined and distinct purpose, so an agent cannot misselect between non-existent alternatives.

Naming Consistency5/5

A single tool inherently exhibits perfect naming consistency, as there are no other tools to compare against. The name 'architect' follows a simple, readable pattern without any conflicting conventions.

Tool Count2/5

One tool is too few for a server named 'MCP Server Template', which implies a broader or more general-purpose scope. A template server should ideally offer multiple tools to demonstrate a range of capabilities, making this count inappropriate for the apparent purpose.

Completeness1/5

The server is severely incomplete for its implied domain as a template. It only provides a single chat interaction tool, lacking any CRUD operations, configuration tools, or other functionalities expected from a template that should showcase a comprehensive tool surface for agents to learn from.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stevennevins/architect-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server