Skip to main content
Glama
Fernandocgomez

DemoTool MCP Server

by Fernandocgomez
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

DemoTool MCP Server

A modular Model Context Protocol (MCP) server for the DemoTool project. This server provides custom tools that AI assistants in Cursor can use to better understand and interact with the codebase.

What is MCP?

Model Context Protocol (MCP) is an open protocol that allows AI assistants to securely interact with external data sources and tools. This server exposes project-specific tools that Cursor can use to enhance development workflows.

Related MCP server: Basic MCP Server

Project Structure

The server is organized into a modular architecture for easy maintenance and scalability:

mcp-server/
├── src/
│   ├── config/           # Server configuration
│   │   ├── server.config.ts
│   │   └── index.ts
│   ├── server/           # Server setup and request handlers
│   │   ├── setup.ts
│   │   └── index.ts
│   ├── tools/            # Tool implementations
│   │   ├── tool-registry.ts    # Tool registry pattern
│   │   ├── hello-world.tool.ts # Example tool
│   │   └── index.ts
│   ├── types/            # TypeScript type definitions
│   │   ├── tool.types.ts
│   │   ├── server.types.ts
│   │   └── index.ts
│   └── index.ts          # Main entry point
├── dist/                 # Compiled JavaScript output
├── package.json
└── tsconfig.json

Available Tools

This MCP server currently provides:

  1. hello_world - Returns a friendly hello world message

    • Optional parameter: name (string) - Name to greet, defaults to "World"

Installation

  1. Install dependencies:

cd mcp-server
npm install

  1. Build the server:

npm run build

Configuration in Cursor

To integrate this MCP server with Cursor:

Method 1: Using Cursor Settings UI

  1. Open Cursor Settings

  2. Navigate to Features → MCP

  3. Click + Add New MCP Server

  4. Configure:

    • Name: kids-daily-tool

    • Type: stdio

    • Command: node /home/fernando/code/kids-daily-tool/mcp-server/dist/index.js

Method 2: Manual Configuration (Advanced)

Edit Cursor's MCP configuration file directly:

Linux/Mac: ~/.config/cursor/mcp.json Windows: %APPDATA%\Cursor\mcp.json

Add this configuration:

{
  "mcpServers": {
    "kids-daily-tool": {
      "command": "node",
      "args": ["/home/fernando/code/kids-daily-tool/mcp-server/dist/index.js"],
      "env": {}
    }
  }
}

Usage in Cursor

Once configured, you can use natural language prompts in Cursor Composer to invoke the tool:

  • "Say hello to me!"

  • "Use the hello_world tool"

  • "Call the hello_world MCP tool with name: Fernando"

Cursor will automatically detect when to use the MCP tool and execute it on your behalf. The tool will return a friendly greeting message.

Development

To modify the server:

  1. Edit files in src/

  2. Rebuild: npm run build

  3. Restart Cursor to pick up changes

Troubleshooting

Server not showing up in Cursor

  • Make sure you've built the server (npm run build)

  • Verify the path in your configuration is absolute

  • Restart Cursor after making configuration changes

Tool errors

  • Check the Cursor Developer Console for error messages

  • Verify file permissions on the project directory

  • Ensure Node.js is available in your PATH

Extending the Server

The modular architecture makes it easy to add new tools. Follow these steps:

1. Create a New Tool

Create a new file in src/tools/, e.g., my-new-tool.tool.ts:

import {
  Tool,
  ToolDefinition,
  ToolArguments,
  ToolResult,
} from "../types/index.js";

export class MyNewTool implements Tool {
  getDefinition(): ToolDefinition {
    return {
      name: "my_new_tool",
      description: "Description of what your tool does",
      inputSchema: {
        type: "object",
        properties: {
          param1: {
            type: "string",
            description: "Description of param1",
          },
        },
        required: ["param1"],
      },
    };
  }

  async execute(args: ToolArguments): Promise<ToolResult> {
    // Implement your tool logic here
    const result = `Processing: ${args.param1}`;

    return {
      content: [
        {
          type: "text",
          text: result,
        },
      ],
    };
  }
}

2. Register the Tool

Add your tool to src/tools/index.ts:

export * from "./my-new-tool.tool.js";
import { MyNewTool } from "./my-new-tool.tool.js";

export function getAllTools(): Tool[] {
  return [
    new HelloWorldTool(),
    new MyNewTool(), // Add your tool here
  ];
}

3. Rebuild and Test

npm run build

That's it! The tool registry will automatically pick up your new tool.

Architecture Benefits

  • Modularity: Each tool is self-contained in its own file

  • Type Safety: Full TypeScript support with proper interfaces

  • Scalability: Easy to add new tools without modifying core logic

  • Maintainability: Clear separation of concerns

  • Testability: Individual tools can be tested in isolation

Security Notes

  • This server only provides read-only access to project information

  • It runs locally and doesn't send data to external services

  • Always review MCP server code before integrating it with your editor

Available Tools

7 tools
angular_component_standardsA

⚠️ REQUIRED TOOL: Must be called before creating or modifying any Angular component. Returns Angular component standards and best practices to ensure code quality and consistency. Can retrieve all standards or filter by specific category.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoOptional category to filter standards (e.g., "signals", "control-flow", "styling", "lifecycle"). If not provided, returns all standards.
listCategoriesNoIf true, returns a list of available standard categories instead of the standards themselves.

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full disclosure burden. It does clarify the two return modes (all standards vs. category list vs. filtered set), but says nothing about whether the content is static reference material, caching, or freshness. For a read-only reference tool this is adequate but thin.

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?

Three sentences, front-loaded with the mandatory-call warning, then purpose, then retrieval modes. No filler, though the ⚠️ prefix and 'REQUIRED TOOL' capitalization are stylistic rather than informational.

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

Completeness4/5

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

For a 2-parameter read-only standards lookup with no output schema, the description covers purpose, timing, and retrieval modes well. It could note that no output schema exists and what the standards payload roughly looks like, but an agent has enough to invoke it correctly.

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?

Schema description coverage is 100% and both parameters are fully documented in the schema, including the example categories and the listCategories behavior. The description's 'filter by specific category' adds no syntax or nuance beyond that, so the baseline 3 applies.

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?

States a specific verb and resource: 'Returns Angular component standards and best practices.' The word 'component' scopes it away from siblings like angular_forms_standards and design_system_standards, though the differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

'Must be called before creating or modifying any Angular component' gives an explicit trigger condition, which is strong when-to-use guidance. It stops short of naming when not to use it or pointing to sibling tools for adjacent topics (forms, data fetching, models).

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

angular_forms_standardsA

⚠️ REQUIRED TOOL: Must be called before creating or modifying forms. Returns Angular forms standards and best practices for reactive forms, FormBuilder usage, and form validation. Can retrieve all standards or filter by specific category.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoOptional category to filter standards (e.g., "formbuilder", "form-groups", "valuechanges-signal", "statuschanges-signal", "rxmethod-side-effects"). If not provided, returns all standards.
listCategoriesNoIf true, returns a list of available standard categories instead of the standards themselves.

TDQS

A3.8/5.0
Behavior3/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. It discloses the key non-obvious behavior — enforceable pre-work requirement and the category-filter vs listCategories alternative — but says nothing about output size, caching, or whether this is purely read-only, which is implied only by "Returns...".

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?

Three sentences, front-loaded with the mandatory-use warning so the critical routing constraint is read first. No filler and every sentence carries distinct information.

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

Completeness4/5

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

For a 2-parameter, no-annotation, no-output-schema retrieval tool this is largely complete: it covers what is returned, the filtering options, and the mandatory call timing. Only the absence of any note on result shape or safety profile keeps it from fully self-contained.

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?

Schema description coverage is 100%, with both parameters already documented including example category values, so the baseline is 3. The description's "can retrieve all standards or filter by specific category" just restates the schema's behavior without adding format or value semantics.

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?

States a concrete verb and resource: returns Angular forms standards and best practices covering reactive forms, FormBuilder and validation. The subject matter clearly separates it from the sibling *_standards tools (components, data fetching, design system, models), though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

"Must be called before creating or modifying forms" gives an explicit trigger condition plus a note that results can be all standards or a filtered category. It stops short of stating when this tool should NOT be used or which sibling to pick for adjacent concerns.

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

data_fetching_standardsA

⚠️ REQUIRED TOOL: Must be called before implementing data fetching or HTTP requests in Angular. Returns data fetching standards and best practices including rxResource, rxRequest, and HTTP patterns. Can retrieve all standards or filter by specific pattern.

ParametersJSON Schema
NameRequiredDescriptionDefault
patternNoOptional pattern to filter standards (e.g., "rxResource", "rxRequest", "http"). If not provided, returns all standards.
listPatternsNoIf true, returns a list of available data fetching patterns instead of the standards themselves.

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the required/pre-emptive nature of the call and that it can return either all standards or a filtered subset, but says nothing about output format, size, or how filtering behaves when no match exists. For a low-risk read-only retrieval tool this is adequate but thin.

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?

Front-loads the most important fact (REQUIRED TOOL, call before implementing) in the first clause. Three sentences with little waste, though 'data fetching standards and best practices' is slightly redundant and could be trimmed.

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

Completeness4/5

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

With no output schema and a simple two-parameter read tool, the description covers purpose, timing, and result scope sufficiently for correct invocation. Minor gaps remain around return shape and behavior when a filter matches nothing.

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?

Schema description coverage is 100%, so the schema already documents both 'pattern' and 'listPatterns' fully. The description's sentence about retrieving all standards or filtering by pattern only restates what the schema already says, adding no new syntax, format, or default guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (returns data fetching standards/best practices) and names the concrete content covered: rxResource, rxRequest, and HTTP patterns. This clearly distinguishes it from siblings like angular_component_standards and angular_forms_standards.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Explicitly states when to call it: 'Must be called before implementing data fetching or HTTP requests in Angular.' That is a clear usage context, though it names no alternative tools or exclusions (e.g., what to use for non-Angular projects).

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

design_system_available_componentsA

📚 Component Registry: Returns comprehensive documentation for all design system components. Use this tool to discover available components (button, card, input, modal, etc.) and learn their APIs, props, events, examples, and usage patterns. Can retrieve all components or filter by specific component name.

ParametersJSON Schema
NameRequiredDescriptionDefault
componentNoOptional component name to filter documentation (e.g., "button", "card", "modal", "input"). If not provided, returns all component documentation.
listComponentsNoIf true, returns a simple list of all available component names instead of full documentation.

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It discloses that the tool returns documentation and supports both unfiltered and filtered retrieval, but it does not mention whether this is strictly read-only, whether there are authentication constraints, rate limits, or the output format. It adds some context but leaves important behavioral traits unaddressed.

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 three sentences and front-loads the registry purpose before mentioning usage and retrieval modes. It is efficient and avoids redundancy, though a small amount of extra detail (e.g., emoji label) is decorative rather than essential.

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

Completeness4/5

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

For a low-complexity, two-optional-parameter tool with no output schema, the description is largely complete: it explains what is returned, what content areas are covered, and how filtering works. It omits only secondary details like output format and size, which are minor given the tool's nature.

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?

Schema description coverage is 100%, so the schema already fully documents both optional parameters. The description repeats the filtering concept and gives example component names, adding only marginal value beyond the schema. A baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Returns comprehensive documentation for all design system components.' It also specifies the discovery intent and the content types (APIs, props, events, examples), making it clearly distinct from sibling tools like design_system_standards or modal_best_practices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description gives implied usage ('Use this tool to discover available components ... and learn their APIs'), but it never states when to prefer this over alternatives or when not to use it. No sibling tools are referenced or excluded.

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

design_system_standardsA

⚠️ REQUIRED TOOL: Must be called before implementing design system components. Returns design system standards and best practices for buttons, cards, inputs, modals, and other components. Can retrieve all standards or filter by specific component.

ParametersJSON Schema
NameRequiredDescriptionDefault
componentNoOptional component to filter standards (e.g., "button", "card", "modal"). If not provided, returns all standards.
listComponentsNoIf true, returns a list of available design system components instead of the standards themselves.

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are present, so the description carries the full behavioral burden. It conveys the read-only retrieval nature and the filter-vs-all behavior, but omits the alternate return shape triggered by listComponents, and gives no sense of output size, formatting, or versioning of the standards. Adequate but incomplete for a tool with zero annotation coverage.

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?

Three tight sentences with the mandatory-call warning front-loaded, followed by capability and filtering behavior. The ⚠️/REQUIRED framing is slightly emphatic but arguably functional for a required tool; no sentence is wasted.

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?

For a two-optional-param, no-annotation, no-output-schema tool, the description covers the main retrieval mode but leaves the listComponents branch (a distinct return shape) unexplained and does not clarify how it relates to the sibling available-components tool. Sufficient to invoke, but an agent could pick the wrong mode.

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?

Schema description coverage is 100%, so both parameters (component, listComponents) are already fully documented in the schema. The description only restates the filter-vs-all behavior ('retrieve all standards or filter by specific component') and never addresses listComponents, so it adds little beyond the schema. Baseline 3 applies.

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?

States a specific verb+resource: returns design system standards and best practices, and enumerates the component coverage (buttons, cards, inputs, modals). However, it offers no differentiation from siblings like angular_component_standards or design_system_available_components, so the agent cannot tell which standards tool applies to which stack from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives a clear triggering condition ('Must be called before implementing design system components'), which is strong when-to-use guidance. It stops short of exclusions or alternatives — notably it never mentions when to prefer design_system_available_components, nor when the listComponents mode (documented only in schema) is the right call.

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

models_standardsA

⚠️ REQUIRED TOOL: Must be called before creating or modifying models. Returns models standards and best practices for model development. Can retrieve all standards or filter by specific category.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoOptional category to filter standards. If not provided, returns all standards.
listCategoriesNoIf true, returns a list of available standard categories instead of the standards themselves.

TDQS

A3.6/5.0
Behavior3/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. It does disclose the mandatory pre-call requirement and that output varies by category/listCategories, but says nothing about the response shape, size, or whether the guidance is authoritative/binding.

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?

Three short sentences, with the critical 'Must be called before creating or modifying models' constraint front-loaded and the warning emoji reinforcing urgency. Slightly redundant between the warning label and the sentence itself, but no real waste.

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

Completeness4/5

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

For a two-parameter, zero-required read tool with no output schema, the description covers purpose, the mandatory-usage constraint, and the filtering modes. The only real gap is what the returned standards actually look like, which is a minor omission here.

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?

Schema coverage is 100%, so both parameters are already documented in the schema and the baseline is 3. The description's 'retrieve all standards or filter by specific category' restates the schema behavior without adding format or syntax detail.

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?

States a specific verb and resource: it returns model development standards and best practices, with the option to filter by category. The resource ('models') distinguishes it from the sibling standards tools (angular_component_standards, design_system_standards, etc.), though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives a clear precondition: it must be called before creating or modifying models, which is exactly the trigger an agent needs. It does not state when NOT to use it or point to a specific sibling tool, so it stops short of a 5.

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.

  1. 7 tool updatesv1.0.0
    • First observedangular_component_standards
    • First observedangular_forms_standards
    • First observeddata_fetching_standards
    • First observeddesign_system_available_components
    • First observeddesign_system_standards
    • First observedmodal_best_practices
    • First observedmodels_standards
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

A3.7/5.0

Scored across 7 tools

Disambiguation4/5

Each tool targets a distinct Angular domain (components, data fetching, forms, models, modals, design system), so most selections are clear. There is mild overlap in the component cluster: design_system_standards explicitly covers modals while modal_best_practices is a separate tool, and design_system_available_components overlaps with design_system_standards.

Naming Consistency4/5

Nearly all tools use snake_case with a <domain>_standards suffix (angular_component_standards, forms, models, design_system, data_fetching). The remaining two (design_system_available_components, modal_best_practices) deviate in suffix but stay readable and consistent in style.

Tool Count5/5

Seven tools is well-scoped for a standards/reference server, with one tool per major Angular concern plus a component registry. No redundancy pushing the count up.

Completeness4/5

Covers the core Angular development concerns plus a component registry, giving solid coverage. Some common areas (routing, state management, testing, services/directives) are absent, but these are reasonable gaps for a standards-focused server.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Basic MCP Server

    gurdasnijor
    A
    license
    Not graded
    quality
    D
    maintenance
    A minimal demonstration server showcasing MCP protocol capabilities including tools, resources, and prompts with basic examples like hello world functionality.
    1 npm
    MIT

  • fast-mcp

    Blakeinstein
    A
    license
    Not graded
    quality
    D
    maintenance
    A minimal MCP server starter template with a simple hello-world tool and Docker support for building AI assistant tools.
    -