Which integrations are available for this server?

Enables discovery, documentation access, and code generation for NTV Scaffolding Angular components, including templates, TypeScript classes, styles, and tests.

How do I use NTV Scaffolding MCP Server?

1. Click on "Install 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., "@NTV Scaffolding MCP Server show me the documentation for the Button component" 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.

NTV Scaffolding MCP Server

by stephenlumban

Overview Schema Related Servers Score Discussions

TypeScript

Remote

🤖 NTV Scaffolding MCP Server

MCP (Model Context Protocol) Server for NTV Scaffolding Components - Enables AI assistants to easily discover, understand, and generate code for NTV Scaffolding Angular components.

🚀 Quick Start

Prerequisites

Node.js 18+
npm or yarn

Installation

# Clone or navigate to the project
cd component-mcp

# Install dependencies
npm install

# Build TypeScript
npm run build

# Start the server
npm start

🔧 Development

# Watch mode (rebuild on changes)
npm run watch

# Run in development mode
npm run dev

📚 Available Tools

The MCP Server provides 7 powerful tools for working with NTV components:

1. list_ntv_components

Lists all available NTV Scaffolding components with filtering options.

Parameters:

category (optional): Filter by category (ui, form, navigation, data, layout, utility)

Example:

{
  "category": "form"
}

2. get_ntv_component_doc

Gets comprehensive documentation for a specific component.

Parameters:

component (required): Component name (e.g., 'Button', 'Input')

Returns:

Component name, selector, category, description
All props with types and defaults
Events, slots, examples
Best practices

3. get_ntv_component_props

Get detailed information about component properties.

Parameters:

component (required): Component name
propName (optional): Specific property to details

Example:

{
  "component": "Button",
  "propName": "variant"
}

4. generate_ntv_template_code

Generates HTML template code for a component with custom configuration.

Parameters:

component (required): Component name
variant (optional): Visual variant
size (optional): Component size
content (optional): Content/text inside
additionalProps (optional): Additional properties
useConfigPattern (optional): Use config pattern. Default: true

Example:

{
  "component": "Button",
  "variant": "primary",
  "size": "lg",
  "content": "Click Me",
  "useConfigPattern": true
}

5. generate_ntv_component_usage

Generates complete component usage examples with TypeScript class and template.

Parameters:

component (required): Component name
usageType (optional): Type of example (basic, advanced, full-form). Default: basic
componentName (optional): Custom component name for example

Example:

{
  "component": "Button",
  "usageType": "advanced",
  "componentName": "CustomButton"
}

6. generate_ntv_component_file

Generates complete component files (TypeScript, template, styles, tests).

Parameters:

component (required): Component name
filename (optional): Output filename in kebab-case
selector (optional): Angular component selector
includeStyles (optional): Include CSS file. Default: true
includeTests (optional): Include test file. Default: true

Example:

{
  "component": "Button",
  "filename": "my-button",
  "selector": "app-my-button",
  "includeStyles": true,
  "includeTests": true
}

7. get_ntv_component_examples

Gets predefined usage examples and code snippets.

Parameters:

component (required): Component name
includeCode (optional): Include code snippets. Default: true

🏗️ Project Structure

component-mcp/
├── src/
│   ├── index.ts                    # Main MCP server entry point
│   ├── tools/
│   │   ├── index.ts               # Tools registry
│   │   ├── listComponents.ts       # List components tool
│   │   ├── getComponentDoc.ts      # Get documentation tool
│   │   ├── getComponentProps.ts    # Get properties tool
│   │   ├── generateTemplateCode.ts # Generate template tool
│   │   ├── generateComponentUsage.ts # Generate usage examples
│   │   ├── generateComponent.ts    # Generate component files
│   │   └── getComponentExamples.ts # Get examples tool
│   ├── data/
│   │   └── components.ts           # Component database
│   └── resources/
│       └── index.ts                # Resource handlers
├── dist/                           # Compiled output
├── package.json
├── tsconfig.json
└── README.md

🧩 Supported Components

The MCP server currently supports:

Button - Versatile button with multiple variants
Input - Form input with validation
Card - Container component
Autocomplete - Input with suggestions
Accordion - Collapsible panels
Stepper - Multi-step workflow
Popover - Contextual tooltip
ThumbnailGallery - Image gallery
Modal - Dialog overlay
Template - Page template layout

💡 Use Cases

For AI Assistants:

Discover Components: Use list_ntv_components to see what's available
Get Documentation: Use get_ntv_component_doc for detailed info
Generate Code: Use generate_ntv_template_code for quick snippets
Create Examples: Use generate_ntv_component_usage for complete examples
Generate Files: Use generate_ntv_component_file for full component files

For Developers:

Quick reference for component APIs
Auto-generation of boilerplate code
Examples and best practices
Type-safe configuration objects

🔌 Integration with Claude/Other AIs

Using with Cursor/Claude:

Start the MCP server: npm start
Configure your AI client to connect to the server
Ask the AI to use the NTV component tools
The AI can generate components, templates, and code

Example Prompts:

"Show me all available form components"
"Generate a Button component with primary variant and large size"
"Create a complete Button component file with tests"
"Show me advanced usage of the Stepper component"
"Generate a form with Button, Input, and Card components"

📖 Component Database

The MCP server includes a comprehensive component database (components.ts) with:

Component metadata (name, selector, category)
All properties with types and defaults
Events and slots
Usage examples
Best practices
Configuration interfaces

To add new components:

Edit src/data/components.ts
Add component metadata to COMPONENTS_DB array
Rebuild: npm run build
Restart server: npm start

🚀 Deployment

Build for production:

npm run build

Run in production:

npm start

Docker (Optional):

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --production
COPY dist ./dist
CMD ["npm", "start"]

🤝 Contributing

To add new tools:

Create a new file in src/tools/
Implement the MCPTool interface
Export it from src/tools/index.ts
The tool will automatically be registered

📝 API Response Format

All tools return responses in this format:

{
  "content": [
    {
      "type": "text",
      "text": "response content here"
    }
  ]
}

🐛 Troubleshooting

Server won't start:

# Check Node version
node --version  # Should be 18+

# Clear cache and reinstall
rm -rf node_modules package-lock.json
npm install
npm run build

Tool not found:

Ensure all imports are correct
Verify tool is exported from tools/index.ts
Check that tool names match exactly

TypeScript errors:

npm run build -- --noEmit

📚 Resources

📄 License

MIT

👨‍💻 Author

NTV Scaffolding Team

Happy coding! 🚀

Available Tools

8 tools

generate_ntv_component_fileB

Generates a complete TypeScript component file that uses an NTV component

ParametersJSON Schema

Name	Required	Description
`component`	Yes	Component name (e.g., 'Button', 'Input')
`filename`	No	Output filename without extension (e.g., 'my-button'). Default: component name in kebab-case
`selector`	No	Angular component selector (e.g., 'app-my-button')
`includeStyles`	No	Include CSS file template. Default: true
`includeTests`	No	Include Jest/Jasmine test template. Default: true

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 'generates' a file, implying a write operation, but doesn't specify where the file is saved (e.g., local filesystem, cloud storage), permissions required, error handling, or output format. For a file-generation tool with zero annotation coverage, this leaves critical 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.

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It avoids redundancy and wastes no words, making it easy to parse quickly. This is an excellent example of conciseness in tool descriptions.

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 complexity (file generation with 5 parameters) and lack of annotations or output schema, the description is minimally adequate. It states what the tool does but misses contextual details like the generated file's structure, dependencies on NTV libraries, or example outputs. For a tool with no output schema, more information on return values or success indicators would improve completeness.

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 input schema has 100% description coverage, documenting all 5 parameters clearly (e.g., 'component' as the component name, 'filename' as output filename). The description adds no additional parameter semantics beyond what the schema provides, such as examples of NTV components or constraints on naming conventions. With high schema coverage, the baseline score of 3 is appropriate.

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: 'Generates a complete TypeScript component file that uses an NTV component.' It specifies the verb ('generates'), resource ('TypeScript component file'), and technology context ('NTV component'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'generate_ntv_template_code' or 'generate_ntv_component_usage,' which might have overlapping purposes.

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. With siblings like 'generate_ntv_template_code' and 'generate_ntv_component_usage,' it's unclear if this tool is for full file generation, partial code snippets, or other contexts. There's no mention of prerequisites, dependencies, or scenarios where this tool is preferred over others.

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

generate_ntv_component_usageC

Generates complete component usage code with TypeScript component class and template

ParametersJSON Schema

Name	Required	Description
`component`	Yes	Component name (e.g., 'Button', 'Input')
`usageType`	No	Type of usage example: basic, advanced, or full-form
`componentName`	No	Custom component name for the example (default: ExampleComponent)

TDQS

C2.9/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 full burden for behavioral disclosure. It states the tool 'Generates' code, implying a write operation, but doesn't cover critical aspects like whether this creates files or returns code snippets, if it requires specific permissions, or any side effects. The description is minimal and lacks behavioral context beyond the basic action.

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, efficient sentence that front-loads the core action and output details without any fluff. Every word earns its place, making it highly concise and well-structured for quick understanding.

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

Completeness2/5

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

Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the generated output looks like (e.g., code format, structure), any prerequisites, or how it integrates with sibling tools. For a code generation tool with multiple parameters, more context is needed to guide effective use.

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 fully documents all three parameters. The description adds no parameter-specific information beyond what's in the schema, such as clarifying relationships between 'component' and 'componentName' or elaborating on 'usageType' enum values. Baseline 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 verb ('Generates') and resource ('complete component usage code') with specific output details ('TypeScript component class and template'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'generate_ntv_component_file' or 'generate_ntv_template_code', which likely generate different artifacts.

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. With siblings like 'get_ntv_component_usage_pattern' and 'get_ntv_component_examples', there's no indication of how this generation tool differs from retrieval tools, leaving the agent to guess based on tool names alone.

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

generate_ntv_template_codeC

Generates HTML template code for an NTV component with optional custom configuration

ParametersJSON Schema

Name	Required	Description
`component`	Yes	Component name (e.g., 'Button', 'Input')
`variant`	No	Visual variant (e.g., 'primary', 'secondary' for Button)
`size`	No	Component size (e.g., 'sm', 'md', 'lg')
`content`	No	Content/text to display inside component
`additionalProps`	No	Additional properties as key-value pairs (e.g., {disabled: true})
`useConfigPattern`	No	Use the config object pattern (recommended for multiple props). Default: true

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 full burden but only states it 'generates' code without disclosing behavioral traits like whether it overwrites existing files, requires specific permissions, or has rate limits. It mentions 'optional custom configuration' but doesn't explain what that entails beyond the schema parameters, leaving gaps in understanding the tool's operation.

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 a single, efficient sentence that front-loads the core purpose. It avoids redundancy and waste, though it could be slightly more structured by explicitly separating purpose from guidance. Every word earns its place, making it appropriately concise for the tool's complexity.

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 no annotations and no output schema, the description is minimally adequate for a code-generation tool with rich schema coverage. It covers the basic purpose but lacks details on behavioral context, output format, or error handling. The schema compensates for parameters, but overall completeness is limited to the bare essentials.

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 fully documents all 6 parameters. The description adds minimal value beyond this, mentioning 'optional custom configuration' which loosely maps to parameters like 'additionalProps' and 'useConfigPattern', but doesn't provide additional meaning or examples. Baseline 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.

Purpose4/5

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

The description clearly states the action ('Generates') and resource ('HTML template code for an NTV component'), specifying it's for template code rather than full component files or documentation. It distinguishes from siblings like 'generate_ntv_component_file' by focusing on templates, though it doesn't explicitly contrast with 'generate_ntv_component_usage' which might be similar.

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 mentions 'optional custom configuration' but provides no guidance on when to use this tool versus alternatives like 'generate_ntv_component_file' for full files or 'get_ntv_component_usage' for usage examples. There's no explicit when-to-use or when-not-to-use context, leaving the agent to guess based on tool names alone.

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

get_ntv_component_docC

Gets comprehensive documentation for a specific NTV component including props, events, and usage patterns

ParametersJSON Schema

Name	Required	Description	Default
`component`	Yes	Component name (e.g., 'Button', 'Input', 'Card', 'Autocomplete')

TDQS

C2.9/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 full burden. It states the tool retrieves documentation, implying a read-only operation, but doesn't disclose behavioral traits such as error handling, response format, whether it requires authentication, or any rate limits. The description is minimal and lacks critical operational context.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.

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

Completeness2/5

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

Given the tool has no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on what the comprehensive documentation includes (e.g., format, structure), how it differs from sibling tools, and behavioral aspects like error cases. For a tool in a family with multiple similar tools, more context is needed to guide effective use.

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 the single parameter 'component' well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as examples of valid component names or constraints. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 action ('Gets') and resource ('comprehensive documentation for a specific NTV component'), specifying it includes props, events, and usage patterns. It distinguishes from some siblings like 'get_ntv_component_props' by being more comprehensive, but doesn't explicitly differentiate from all related tools like 'get_ntv_component_examples'.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for getting comprehensive documentation, but doesn't specify scenarios where this is preferred over siblings like 'get_ntv_component_examples' or 'get_ntv_component_props', nor does it mention prerequisites or exclusions.

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

get_ntv_component_examplesB

Gets predefined usage examples and code snippets for a specific component

ParametersJSON Schema

Name	Required	Description	Default
`component`	Yes	Component name (e.g., 'Button', 'Input')
`includeCode`	No	Include full code snippets in response. Default: true

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 'Gets' examples and snippets, implying a read-only operation, but does not disclose any behavioral traits such as rate limits, authentication needs, error handling, or what the response format looks like. This is a significant gap for a tool with no 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.

Conciseness5/5

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 to parse quickly, earning the highest score for conciseness.

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 moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects and usage context. Without an output schema, it does not explain return values, and with no annotations, it misses safety or operational hints, making it incomplete for optimal agent use.

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 input schema has 100% description coverage, clearly documenting both parameters ('component' and 'includeCode'). The description adds no additional meaning beyond what the schema provides, such as examples of component names beyond 'Button' and 'Input' or details on code snippet formats. With high schema coverage, the baseline score of 3 is appropriate.

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 ('Gets') and resource ('predefined usage examples and code snippets for a specific component'), making it easy to understand what it does. However, it does not explicitly differentiate from sibling tools like 'get_ntv_component_doc' or 'get_ntv_component_usage_pattern', which might have overlapping or similar functions, so it misses the highest 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 no guidance on when to use this tool versus alternatives, such as sibling tools like 'get_ntv_component_doc' or 'generate_ntv_component_usage'. It lacks explicit context, exclusions, or prerequisites, leaving the agent to infer usage based on the name and description alone.

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

get_ntv_component_propsC

Get detailed information about a component's input properties and configuration options

ParametersJSON Schema

Name	Required	Description	Default
`component`	Yes	Component name (e.g., 'Button', 'Input')
`propName`	No	Optional: Get details for a specific property

TDQS

C2.9/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 full burden. It describes a read operation ('Get detailed information'), which implies it's non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or response format. The description is minimal and lacks context beyond the basic operation.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing to understanding the tool's function.

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

Completeness2/5

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

Given no annotations, no output schema, and a read operation with 2 parameters, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are structured, or any limitations. For a tool with siblings and potential complexity, more context is needed to guide effective use.

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 parameters ('component' and 'propName') with descriptions. The description adds no additional meaning beyond what the schema provides, such as examples of property details or configuration options. Baseline 3 is appropriate when 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 purpose with a specific verb ('Get') and resource ('detailed information about a component's input properties and configuration options'). It distinguishes itself from siblings like 'get_ntv_component_doc' or 'get_ntv_component_examples' by focusing on properties/configuration, but doesn't explicitly contrast them.

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 'get_ntv_component_doc' or 'list_ntv_components'. It mentions an optional parameter but doesn't explain scenarios for using it or prerequisites for tool invocation.

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

get_ntv_component_usage_patternC

Gets the proper Angular standalone component usage pattern for a specific NTV component

ParametersJSON Schema

Name	Required	Description	Default
`component`	Yes	Component name (e.g., 'Button', 'Input', 'Card')

TDQS

C2.9/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 a read operation ('Gets'), which suggests it's non-destructive, but doesn't clarify aspects like authentication needs, rate limits, error handling, or the format of the returned usage pattern (e.g., text, code snippet). This leaves significant gaps for safe and effective tool invocation.

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 a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could benefit from slightly more detail to improve completeness without sacrificing brevity.

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 moderate complexity (a read operation with one parameter) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format, which are needed for a more complete understanding, especially without structured fields to fill gaps.

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 input schema has 100% description coverage, with the 'component' parameter well-documented as 'Component name (e.g., 'Button', 'Input', 'Card')'. The description adds no additional meaning beyond this, such as clarifying valid component names or constraints, so it meets the baseline for high schema coverage without compensating value.

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 action ('Gets') and the resource ('proper Angular standalone component usage pattern for a specific NTV component'), making the purpose understandable. It distinguishes from siblings like 'get_ntv_component_doc' or 'get_ntv_component_examples' by focusing on usage patterns, but could be more specific about what a 'usage pattern' entails (e.g., code structure, 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 Guidelines2/5

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

No explicit guidance is provided on when to use this tool versus alternatives like 'get_ntv_component_examples' or 'generate_ntv_component_usage'. The description implies usage for a 'specific NTV component', but lacks context on prerequisites, scenarios, or exclusions, leaving the agent to infer based on tool names alone.

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

list_ntv_componentsB

Lists all available NTV Scaffolding components with their basic information

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter by category: ui, form, navigation, data, layout, utility

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 lists components but doesn't describe the return format (e.g., JSON array, pagination), potential rate limits, authentication needs, or whether it's a read-only operation. This leaves significant gaps in understanding 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.

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the key action ('Lists all available NTV Scaffolding components') and specifies the output ('with their basic information'). There is no wasted language, and it directly communicates the tool's purpose without unnecessary details.

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 (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits like return format or usage context. For a listing tool with no annotations, it should ideally include more about what 'basic information' entails or how results are structured to be fully complete.

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 the single parameter 'category' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, such as examples of categories or default behavior when no category is specified. Baseline 3 is appropriate since the schema handles parameter documentation adequately.

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 verb ('Lists') and resource ('NTV Scaffolding components'), specifying what information is returned ('basic information'). It distinguishes from siblings like get_ntv_component_doc or get_ntv_component_examples by focusing on listing all components rather than detailed documentation. However, it doesn't explicitly differentiate from get_ntv_component_props or get_ntv_component_usage_pattern, which might also list components with different attributes.

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 prerequisites, such as needing access to NTV Scaffolding, or compare it to siblings like generate_ntv_component_file for creating components. Usage is implied only by the action of listing, with no explicit context or exclusions provided.

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. Dates show when Glama detected each change.

8 tool updatesv1.0.0Nov 3, 2025
- First observedgenerate_ntv_component_file
- First observedgenerate_ntv_component_usage
- First observedgenerate_ntv_template_code
- First observedget_ntv_component_doc
- First observedget_ntv_component_examples
- First observedget_ntv_component_props
- First observedget_ntv_component_usage_pattern
- First observedlist_ntv_components

Install Server

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

TDQS

B3.4/5.0

Disambiguation4/5

Most tools have distinct purposes, but there is some overlap between 'get_ntv_component_doc' and 'get_ntv_component_examples' as both provide usage information, which could cause mild confusion. The other tools are clearly differentiated by their specific functions like generation, listing, or property retrieval.

Naming Consistency5/5

All tools follow a consistent snake_case naming pattern with clear verb_noun structure, such as 'generate_ntv_component_file' and 'get_ntv_component_doc'. This predictability makes it easy for agents to understand and select the right tool based on naming conventions.

Tool Count5/5

With 8 tools, the server is well-scoped for its purpose of scaffolding NTV components, covering generation, documentation, and listing operations. Each tool serves a specific role without feeling excessive or insufficient for the domain.

Completeness4/5

The toolset provides comprehensive coverage for generating and retrieving component information, but lacks update or delete operations, which are minor gaps since the domain focuses on scaffolding and documentation rather than lifecycle management. Agents can still perform core workflows effectively.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Tseha AFeatured
io.tseha
Serves your design system and coding standards to coding agents, so they stop guessing.
Developer Tools Documentation Access
93
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
@imqueue A
org.imqueue
Search @imqueue docs and scaffold typed services & clients from your AI coding agent.
Developer Tools Documentation Access
711
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/stephenlumban/component-mcp'

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