Skip to main content
Glama
hnkatze

PrimeNG MCP Server

by hnkatze
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

PrimeNG MCP Server

License: MIT TypeScript Node

Servidor MCP (Model Context Protocol) para acceder a la documentación de componentes PrimeNG y generar código Angular.

✨ Características

  • 📚 Documentación completa - Extrae properties, events, methods y descripciones

  • 🔍 Búsqueda inteligente - Encuentra componentes por nombre o categoría

  • 💻 Generación de código - Crea componentes Angular listos para usar

  • 📝 Múltiples ejemplos - Extrae todos los ejemplos de código de PrimeNG.org

  • ⚡ Cache persistente - Almacena documentación en disco con TTL configurable

  • 🌐 Web scraping robusto - Sistema de reintentos con exponential backoff

  • 🎨 Syntax highlighting - Auto-detección de lenguaje para formateo

  • 📖 Guías de configuración - Documentación de instalación, theming, iconos, etc.

Related MCP server: Vue Prime MCP Server

Instalación

npm install
npm run build

Uso en Desarrollo

npm run dev

Configuración en Claude Desktop

Añade lo siguiente a tu archivo de configuración de Claude Desktop:

MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "primeng": {
      "command": "node",
      "args": ["/ruta/absoluta/a/primeng-mcp-server/dist/index.js"]
    }
  }
}

O en modo desarrollo:

{
  "mcpServers": {
    "primeng": {
      "command": "npx",
      "args": ["-y", "tsx", "/ruta/absoluta/a/primeng-mcp-server/src/index.ts"]
    }
  }
}

Herramientas Disponibles

1. get_component_doc

Obtiene documentación completa de un componente.

Parámetros:

  • component (string): Nombre del componente (ej: "button", "table", "dialog")

Ejemplo de uso:

¿Cuáles son las propiedades del componente Button de PrimeNG?

2. search_components

Busca componentes por término.

Parámetros:

  • query (string): Término de búsqueda

Ejemplo de uso:

Busca componentes de PrimeNG relacionados con "input"

3. list_all_components

Lista todos los componentes disponibles organizados por categoría.

Ejemplo de uso:

Muéstrame todos los componentes de PrimeNG

4. generate_component_code

Genera código de ejemplo para un componente.

Parámetros:

  • component (string): Nombre del componente

  • properties (object, opcional): Propiedades del componente

Ejemplo de uso:

Genera código para un botón con label "Guardar" y icono "pi pi-save"

5. get_component_examples

Obtiene todos los ejemplos de código extraídos de la documentación oficial.

Parámetros:

  • component (string): Nombre del componente

Mejoras (v2.0):

  • ✨ Extrae todos los ejemplos del sitio web (no solo 1-3 hardcodeados)

  • ✨ Auto-detección de lenguaje (HTML, TypeScript, etc.)

  • ✨ Cache-first para respuestas rápidas

  • ✨ Fallback a ejemplos hardcodeados si falla el scraping

Ejemplo de uso:

Dame ejemplos de cómo usar el componente Table de PrimeNG

Resultado: ~18 ejemplos para Button, ~7 para Dialog, etc.

Componentes Soportados

El servidor incluye más de 70 componentes de PrimeNG:

  • Inputs: autocomplete, calendar, checkbox, dropdown, inputtext, etc.

  • Data: datatable, table, dataview, tree, etc.

  • Buttons: button, splitbutton, speeddial

  • Panels: accordion, card, panel, tabview, etc.

  • Overlays: dialog, sidebar, tooltip

  • Menus: breadcrumb, menu, menubar, megamenu, etc.

  • Messages: message, toast

  • Media: carousel, galleria, image

  • Y muchos más...

Ejemplos de Consultas

1. "¿Cómo uso el componente Calendar de PrimeNG?"
2. "Genera un dialog con header y footer"
3. "Busca componentes de menú"
4. "Dame ejemplos del componente Table"
5. "Lista todos los componentes de entrada"

🏗️ Arquitectura (v2.0)

El proyecto sigue una arquitectura modular y escalable:

primeng-mcp-server/
├── src/
│   ├── index.ts              # Entry point
│   ├── server/
│   │   └── PrimeNGServer.ts  # Main server class
│   ├── services/
│   │   ├── ScraperService.ts       # Web scraping & HTML parsing
│   │   ├── CacheService.ts         # Persistent cache with TTL
│   │   ├── CodeGeneratorService.ts # Code generation
│   │   └── DocsScraperService.ts   # Guide documentation scraping
│   ├── tools/
│   │   ├── BaseTool.ts             # Abstract base class
│   │   ├── GetComponentDocTool.ts  # Tool: get_component_doc
│   │   ├── SearchComponentsTool.ts # Tool: search_components
│   │   ├── ListComponentsTool.ts   # Tool: list_all_components
│   │   ├── GenerateCodeTool.ts     # Tool: generate_component_code
│   │   ├── GetExamplesTool.ts      # Tool: get_component_examples
│   │   └── Get*GuideTool.ts        # Guide tools (installation, theming, etc)
│   ├── models/
│   │   ├── ComponentDoc.ts   # Interfaces and types
│   │   └── ToolSchemas.ts    # MCP tool schemas
│   ├── utils/
│   │   ├── logger.ts         # Structured logging
│   │   ├── formatters.ts     # Output formatting
│   │   ├── parsers.ts        # HTML parsing utilities
│   │   ├── errors.ts         # Custom error classes
│   │   └── retry.ts          # Retry with exponential backoff
│   └── config/
│       └── constants.ts      # Configuration
├── tests/
│   └── unit/                 # Unit tests
├── dist/                     # Compiled JavaScript
├── .cache/                   # Component cache (gitignored)
└── docs/                     # Documentation (CLAUDE.md, CONTRIBUTING.md, etc)

💻 Desarrollo

Scripts Disponibles

npm run build         # Compile TypeScript
npm run watch         # Compile with watch mode
npm run dev           # Run with tsx (no compilation)
npm start             # Run compiled version
npm test              # Run tests
npm run test:unit     # Run unit tests only
npm run test:coverage # Run with coverage
npm run lint          # Lint code
npm run lint:fix      # Auto-fix lint issues
npm run format        # Format with Prettier

Añadir un Nuevo Tool

  1. Crea el tool en src/tools/MyNewTool.ts extendiendo BaseTool

  2. Define el schema en src/models/ToolSchemas.ts

  3. Registra en src/server/PrimeNGServer.ts:

    • Inicializa en initializeTools()

    • Agrega case en el handler CallToolRequestSchema

    • Agrega schema en ListToolsRequestSchema

Ejemplo:

// src/tools/MyNewTool.ts
import { BaseTool, ToolResponse } from './BaseTool.js';

export class MyNewTool extends BaseTool {
  constructor(dependencies) {
    super('my_new_tool');
  }

  async execute(args: Record<string, any>): Promise<ToolResponse> {
    // Tu lógica aquí
    return this.createResponse(result);
  }
}

Modificar el Scraping

  • Lógica de scraping: src/services/ScraperService.ts

  • Parsers HTML: src/utils/parsers.ts

  • Formateo de salida: src/utils/formatters.ts

Ver CLAUDE.md para documentación detallada de arquitectura.

🎯 Mejoras Recientes (v2.0)

  • ✅ Web scraping completo - Extrae documentación real de PrimeNG.org

  • ✅ Cache persistente - Sistema de cache en .cache/ con TTL de 24h

  • ✅ Múltiples ejemplos - Extrae TODOS los ejemplos (no solo el primero)

  • ✅ Sin límites - Elimina límites de 20 properties, 15 events, 10 methods

  • ✅ Descripciones completas - Sin truncamiento a 100 caracteres

  • ✅ Arquitectura modular - Separación en services, tools, utils

  • ✅ Sistema de logging - Logger estructurado con niveles

  • ✅ Reintentos robustos - Exponential backoff para web scraping

  • ✅ Testing - Framework Vitest configurado

  • ✅ Code quality - ESLint + Prettier

🚧 Roadmap

  • Soporte para API documentation tabs en nueva estructura PrimeNG

  • Validación de propiedades con schemas

  • Generación de tests unitarios

  • Integración con PrimeNG CLI

  • Generación de código TypeScript para lógica

  • Soporte para temas y estilos customizados

  • CLI tool para testing local

🤝 Contribuir

¡Las contribuciones son bienvenidas! Por favor lee CONTRIBUTING.md para detalles sobre:

  • Cómo reportar bugs

  • Cómo proponer nuevas características

  • Guías de estilo de código

  • Proceso de pull requests

📄 Licencia

Este proyecto está licenciado bajo la Licencia MIT - ver el archivo LICENSE para más detalles.

📚 Recursos

👥 Autores

PrimeNG MCP Server Contributors

🙏 Agradecimientos

  • PrimeNG team por su excelente biblioteca de componentes

  • Anthropic por el Model Context Protocol

  • Comunidad open source

¿Preguntas o problemas? Abre un issue

Available Tools

9 tools
generate_component_codeB

Genera código de ejemplo para un componente de PrimeNG con las propiedades especificadas

ParametersJSON Schema
NameRequiredDescriptionDefault
componentYesNombre del componente
propertiesNoPropiedades del componente (ej: {label: 'Click me', icon: 'pi pi-check'})

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 code, implying a read-only or informational operation, but doesn't clarify if this involves mutations (e.g., creating files), authentication needs, rate limits, or output format. The description lacks details on what the generated code includes (e.g., HTML, TypeScript, styling) or any constraints, leaving significant behavioral gaps.

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 in Spanish that directly states the tool's function without unnecessary words. It's front-loaded with the core action ('Genera código de ejemplo') and specifies the target and inputs concisely. Every part of the sentence contributes to understanding the purpose, making it well-structured and appropriately sized.

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 (2 parameters, one with an enum, no output schema), the description is adequate but incomplete. It clarifies the purpose and inputs but lacks output details (e.g., code format, language), behavioral context (e.g., whether it's a read operation), and differentiation from siblings. With no annotations and no output schema, the description should do more to compensate, but it meets a minimum viable threshold for a code-generation tool.

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 clear descriptions for both parameters: 'component' (nombre del componente) and 'properties' (propiedades del componente). The description adds minimal value beyond the schema, as it only reiterates that properties are specified without providing additional syntax, examples, or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.

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: 'Genera código de ejemplo para un componente de PrimeNG con las propiedades especificadas' (Generates sample code for a PrimeNG component with the specified properties). It specifies the verb ('genera'), resource ('código de ejemplo'), and target ('componente de PrimeNG'), making the purpose clear. However, it doesn't explicitly differentiate from siblings like 'get_component_examples' or 'get_component_doc', which might also provide code-related information.

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 siblings like 'get_component_examples' (which might retrieve existing examples) or 'list_all_components' (which might list available components), leaving the agent to infer usage context. There's no explicit when-to-use or when-not-to-use information, resulting in minimal guidance.

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

get_component_docC

Obtiene la documentación completa de un componente de PrimeNG incluyendo propiedades, eventos y métodos

ParametersJSON Schema
NameRequiredDescriptionDefault
componentYesNombre del componente de PrimeNG (ej: 'button', 'table', 'dialog')

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. While it indicates this is a read operation ('obtiene'), it doesn't describe what the output looks like (e.g., format, structure, or content details beyond 'propiedades, eventos y métodos'), potential errors, or any constraints like rate limits. For a tool with no annotations and no output schema, this leaves significant gaps in understanding how it 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, efficient sentence in Spanish that front-loads the core purpose without unnecessary details. It uses clear language ('obtiene la documentación completa') and specifies the included elements ('propiedades, eventos y métodos'), making it appropriately sized with zero waste.

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 complexity (a documentation retrieval tool with no annotations and no output schema), the description is incomplete. It states what the tool does but lacks details on output format, error handling, or behavioral traits. Without annotations or an output schema, the agent has insufficient information to understand the full context of use, especially compared to siblings like 'get_component_examples'.

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 schema description coverage is 100%, with the single parameter 'component' fully documented in the schema (including description and enum values). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how the component name maps to documentation or any nuances in selection. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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: 'Obtiene la documentación completa de un componente de PrimeNG incluyendo propiedades, eventos y métodos' (Gets the complete documentation of a PrimeNG component including properties, events, and methods). It specifies the verb ('obtiene'), resource ('documentación de un componente de PrimeNG'), and scope ('completa... incluyendo propiedades, eventos y métodos'). However, it doesn't explicitly differentiate from siblings like 'list_all_components' or 'get_component_examples', which would require a 5.

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 sibling tools like 'get_component_examples' (for examples) or 'list_all_components' (for listing components), nor does it specify prerequisites or contexts for usage. The agent must infer usage from the purpose alone, which is insufficient for clear differentiation.

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

get_component_examplesB

Obtiene ejemplos de uso prácticos de un componente específico

ParametersJSON Schema
NameRequiredDescriptionDefault
componentYesNombre del componente

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. While 'obtiene' (gets) implies a read-only operation, the description doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this is a significant gap in behavioral context.

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's appropriately sized for a simple tool with one parameter, and every part of the sentence contributes to understanding what the tool does.

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 parameter with full schema coverage) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but fails to provide guidance on usage versus siblings or behavioral details, leaving gaps that could hinder effective tool invocation in a broader 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 adds minimal value beyond the input schema. It mentions 'un componente específico' (a specific component), which aligns with the 'component' parameter, but the schema already has 100% coverage with a clear description and enum list. Since schema_description_coverage is high, the baseline is 3, and the description doesn't provide additional syntax or format details to elevate the score.

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: 'Obtiene ejemplos de uso prácticos de un componente específico' (Gets practical usage examples of a specific component). It specifies the verb 'obtiene' (gets) and resource 'ejemplos de uso prácticos' (practical usage examples), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_component_doc' or 'generate_component_code', which is why it doesn't reach 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 no guidance on when to use this tool versus alternatives. With siblings like 'get_component_doc' (documentation), 'generate_component_code' (code generation), and 'list_all_components' (listing), there's no indication of when this tool is preferred for examples versus other purposes. This leaves the agent without context for tool selection.

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

get_icons_guideB

Obtiene la guía de uso de PrimeIcons

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 only states what the tool does ('Obtiene la guía de uso') without mentioning any behavioral traits like whether it returns a file, text, or structured data; if it requires authentication; or if there are rate limits. This leaves significant gaps 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 in Spanish ('Obtiene la guía de uso de PrimeIcons') that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple, no-parameter tool and is front-loaded with the core action.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'la guía de uso' entails (e.g., a document, examples, or instructions), how the output is structured, or any prerequisites. For a tool with no structured data to rely on, this leaves the agent with insufficient context to use it effectively.

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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters, earning a baseline score of 4 for not introducing confusion or redundancy.

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 ('Obtiene' - Gets) and the resource ('la guía de uso de PrimeIcons'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_installation_guide' or 'get_theming_guide' that also retrieve guides, leaving some ambiguity about what specifically distinguishes this tool.

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 sibling tools like 'get_installation_guide' and 'get_theming_guide' available, there's no indication of whether this is for general usage instructions, specific icon documentation, or something else, leaving the agent to guess based on the tool name alone.

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

get_installation_guideB

Obtiene la guía de instalación y configuración inicial de PrimeNG

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/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 but offers minimal information. It states what the tool does ('gets the installation guide') but doesn't describe return format, error conditions, rate limits, authentication needs, or other behavioral traits. This leaves significant gaps 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.

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's appropriately sized for a simple tool and front-loads the essential information, making it easy to parse quickly.

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 lack of annotations and output schema, the description is incomplete for effective tool use. While it states what the tool retrieves, it doesn't explain what format the installation guide comes in (e.g., text, HTML, structured data), potential limitations, or how to handle the result. For a tool with no structured behavioral hints, this leaves too many unknowns.

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 tool has zero parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for a parameterless tool. A baseline of 4 is appropriate since there's nothing to compensate for.

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 ('obtiene' - gets) and resource ('guía de instalación y configuración inicial de PrimeNG'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_tailwind_guide' or 'get_theming_guide' beyond the resource name, which prevents 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or exclusions, leaving the agent to infer usage based solely on the tool name and description without explicit direction.

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

get_tailwind_guideB

Obtiene la guía de integración de PrimeNG con Tailwind CSS

ParametersJSON Schema
NameRequiredDescriptionDefault

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 states the tool 'gets' a guide, implying a read-only operation, but doesn't specify whether this requires authentication, involves rate limits, returns structured or unstructured data, or has any side effects. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 in Spanish that directly states the tool's purpose without unnecessary words. It is appropriately sized for a no-parameter tool and front-loads the key action ('obtiene'). There is no wasted language or redundant information.

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 has 0 parameters, no annotations, and no output schema, the description is minimally complete. It tells the agent what resource to fetch, but doesn't explain the format of the returned guide (e.g., text, HTML, JSON) or any prerequisites. For a simple read operation, this might be adequate, but it lacks depth for more complex use cases.

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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as the description doesn't mislead about parameters and the schema fully covers the absence of them.

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: 'Obtiene la guía de integración de PrimeNG con Tailwind CSS' (Gets the integration guide for PrimeNG with Tailwind CSS). It specifies the verb 'obtiene' (gets) and the resource 'guía de integración' (integration guide), making the action and target clear. However, it doesn't explicitly differentiate from sibling tools like 'get_installation_guide' or 'get_theming_guide', which might also provide guides but for different topics.

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 when this specific integration guide is needed, what context it applies to, or how it differs from other guide-fetching siblings like 'get_installation_guide' or 'get_theming_guide'. Without such context, users must infer usage based on the tool name alone.

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

get_theming_guideB

Obtiene la guía de theming de PrimeNG (temas, personalización, modo oscuro)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 retrieves a theming guide but doesn't describe what the return format looks like (e.g., text, structured data), whether it's cached, if there are rate limits, or any authentication needs. 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.

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 includes relevant details (temas, personalización, modo oscuro) without unnecessary elaboration. However, it could be slightly more structured by explicitly separating the purpose from the content scope.

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 has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavioral traits, return format, or usage context. For a simple retrieval tool, this might suffice, but it doesn't fully compensate for the lack of structured data, leaving gaps in understanding how to use it effectively.

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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. Baseline 4 is applied for zero-parameter tools, as no compensation is needed.

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 ('Obtiene') and resource ('guía de theming de PrimeNG'), including what content it covers (temas, personalización, modo oscuro). It distinguishes itself from siblings like get_installation_guide or get_tailwind_guide by focusing on theming. However, it doesn't explicitly differentiate from all siblings (e.g., get_icons_guide is also a guide-type tool).

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, context for usage, or compare it to siblings like get_component_doc or search_components for related information. Usage is implied by the purpose but not explicitly stated.

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

list_all_componentsB

Lista todos los componentes disponibles en PrimeNG con una breve descripción

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/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 what the tool does, not how it behaves. It doesn't mention response format, pagination, rate limits, authentication needs, or error handling. The description adds no behavioral 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 with zero wasted words. It's appropriately sized and front-loaded with the core functionality.

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?

For a read-only listing tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned (beyond 'brief description'), format, structure, or any limitations. The context signals indicate this tool needs more complete documentation.

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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for this dimension.

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 ('Lista todos los componentes') and target resource ('componentes disponibles en PrimeNG'), with additional detail about including brief descriptions. It doesn't explicitly differentiate from sibling tools like 'search_components', but the purpose is unambiguous.

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 guidance is provided about when to use this tool versus alternatives like 'search_components' or 'get_component_doc'. The description implies a comprehensive listing, but lacks explicit usage context or exclusions.

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

search_componentsC

Busca componentes de PrimeNG que coincidan con una consulta

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesTérmino de búsqueda (ej: 'input', 'table', 'menu')

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 only states what the tool does (searches) without describing how it behaves: no information on return format, pagination, error handling, or performance characteristics. For a search 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality. Every word earns its place in this concise formulation.

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 lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what the search returns (e.g., component names, metadata, or full details), how results are structured, or any limitations. For a search functionality that presumably returns data, this leaves significant gaps in understanding the tool's behavior and outputs.

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 'query' well-documented in the schema. The description doesn't add any parameter semantics beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting. No additional value is provided for parameter understanding.

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 ('Busca' - searches) and resource ('componentes de PrimeNG'), indicating it searches for PrimeNG components matching a query. However, it doesn't explicitly differentiate from sibling tools like 'list_all_components' or 'get_component_doc', which reduces clarity about when to use this versus alternatives.

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 multiple sibling tools available (e.g., 'list_all_components', 'get_component_doc'), there's no indication of when search is preferred over listing all components or accessing documentation directly. This leaves the agent without context for tool selection.

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.

  1. 3 tool updatesv1.0.0
    • Changedgenerate_component_code1 field changed
      • changedInput schema / properties / component / enum
        Previous value: -[
-  "accordion",
-  "animateonscroll",
-  "autocomplete",
-  "autofocus",
-  "avatar",
-  "badge",
-  "bind",
-  "blockui",
-  "breadcrumb",
-  "button",
-  "card",
-  "carousel",
-  "cascadeselect",
-  "checkbox",
-  "chip",
-  "colorpicker",
-  "confirmdialog",
-  "confirmpopup",
-  "contextmenu",
-  "dataview",
-  "datepicker",
-  "dialog",
-  "divider",
-  "dock",
-  "drawer",
-  "dynamicdialog",
-  "editor",
-  "fieldset",
-  "fileupload",
-  "floatlabel",
-  "fluid",
-  "focustrap",
-  "galleria",
-  "iconfield",
-  "iftalabel",
-  "image",
-  "imagecompare",
-  "inplace",
-  "inputgroup",
-  "inputmask",
-  "inputnumber",
-  "inputotp",
-  "inputtext",
-  "keyfilter",
-  "knob",
-  "listbox",
-  "megamenu",
-  "menu",
-  "menubar",
-  "message",
-  "metergroup",
-  "multiselect",
-  "orderlist",
-  "organizationchart",
-  "paginator",
-  "panel",
-  "panelmenu",
-  "passthrough",
-  "password",
-  "picklist",
-  "popover",
-  "progressbar",
-  "progressspinner",
-  "radiobutton",
-  "rating",
-  "ripple",
-  "scrollpanel",
-  "scrolltop",
-  "select",
-  "selectbutton",
-  "skeleton",
-  "slider",
-  "speeddial",
-  "splitbutton",
-  "splitter",
-  "stepper",
-  "styleclass",
-  "table",
-  "tabs",
-  "tag",
-  "terminal",
-  "textarea",
-  "tieredmenu",
-  "timeline",
-  "toast",
-  "togglebutton",
-  "toggleswitch",
-  "toolbar",
-  "tooltip",
-  "tree",
-  "treeselect",
-  "treetable",
-  "virtualscroller"
-]New value: +[
+  "accordion",
+  "animateonscroll",
+  "autocomplete",
+  "autofocus",
+  "avatar",
+  "badge",
+  "bind",
+  "blockui",
+  "breadcrumb",
+  "button",
+  "card",
+  "carousel",
+  "cascadeselect",
+  "checkbox",
+  "chip",
+  "colorpicker",
+  "confirmdialog",
+  "confirmpopup",
+  "contextmenu",
+  "dataview",
+  "datepicker",
+  "dialog",
+  "divider",
+  "dock",
+  "drawer",
+  "dynamicdialog",
+  "editor",
+  "fieldset",
+  "fileupload",
+  "floatlabel",
+  "fluid",
+  "focustrap",
+  "galleria",
+  "iconfield",
+  "iftalabel",
+  "image",
+  "imagecompare",
+  "inplace",
+  "inputgroup",
+  "inputmask",
+  "inputnumber",
+  "inputotp",
+  "inputtext",
+  "keyfilter",
+  "knob",
+  "listbox",
+  "llms",
+  "mcp",
+  "megamenu",
+  "menu",
+  "menubar",
+  "message",
+  "metergroup",
+  "multiselect",
+  "orderlist",
+  "organizationchart",
+  "paginator",
+  "panel",
+  "panelmenu",
+  "passthrough",
+  "password",
+  "picklist",
+  "popover",
+  "progressbar",
+  "progressspinner",
+  "radiobutton",
+  "rating",
+  "ripple",
+  "scrollpanel",
+  "scrolltop",
+  "select",
+  "selectbutton",
+  "skeleton",
+  "slider",
+  "speeddial",
+  "splitbutton",
+  "splitter",
+  "stepper",
+  "styleclass",
+  "table",
+  "tabs",
+  "tag",
+  "terminal",
+  "textarea",
+  "tieredmenu",
+  "timeline",
+  "toast",
+  "togglebutton",
+  "toggleswitch",
+  "toolbar",
+  "tooltip",
+  "tree",
+  "treeselect",
+  "treetable",
+  "virtualscroller"
+]
    • Changedget_component_doc1 field changed
      • changedInput schema / properties / component / enum
        Previous value: -[
-  "accordion",
-  "animateonscroll",
-  "autocomplete",
-  "autofocus",
-  "avatar",
-  "badge",
-  "bind",
-  "blockui",
-  "breadcrumb",
-  "button",
-  "card",
-  "carousel",
-  "cascadeselect",
-  "checkbox",
-  "chip",
-  "colorpicker",
-  "confirmdialog",
-  "confirmpopup",
-  "contextmenu",
-  "dataview",
-  "datepicker",
-  "dialog",
-  "divider",
-  "dock",
-  "drawer",
-  "dynamicdialog",
-  "editor",
-  "fieldset",
-  "fileupload",
-  "floatlabel",
-  "fluid",
-  "focustrap",
-  "galleria",
-  "iconfield",
-  "iftalabel",
-  "image",
-  "imagecompare",
-  "inplace",
-  "inputgroup",
-  "inputmask",
-  "inputnumber",
-  "inputotp",
-  "inputtext",
-  "keyfilter",
-  "knob",
-  "listbox",
-  "megamenu",
-  "menu",
-  "menubar",
-  "message",
-  "metergroup",
-  "multiselect",
-  "orderlist",
-  "organizationchart",
-  "paginator",
-  "panel",
-  "panelmenu",
-  "passthrough",
-  "password",
-  "picklist",
-  "popover",
-  "progressbar",
-  "progressspinner",
-  "radiobutton",
-  "rating",
-  "ripple",
-  "scrollpanel",
-  "scrolltop",
-  "select",
-  "selectbutton",
-  "skeleton",
-  "slider",
-  "speeddial",
-  "splitbutton",
-  "splitter",
-  "stepper",
-  "styleclass",
-  "table",
-  "tabs",
-  "tag",
-  "terminal",
-  "textarea",
-  "tieredmenu",
-  "timeline",
-  "toast",
-  "togglebutton",
-  "toggleswitch",
-  "toolbar",
-  "tooltip",
-  "tree",
-  "treeselect",
-  "treetable",
-  "virtualscroller"
-]New value: +[
+  "accordion",
+  "animateonscroll",
+  "autocomplete",
+  "autofocus",
+  "avatar",
+  "badge",
+  "bind",
+  "blockui",
+  "breadcrumb",
+  "button",
+  "card",
+  "carousel",
+  "cascadeselect",
+  "checkbox",
+  "chip",
+  "colorpicker",
+  "confirmdialog",
+  "confirmpopup",
+  "contextmenu",
+  "dataview",
+  "datepicker",
+  "dialog",
+  "divider",
+  "dock",
+  "drawer",
+  "dynamicdialog",
+  "editor",
+  "fieldset",
+  "fileupload",
+  "floatlabel",
+  "fluid",
+  "focustrap",
+  "galleria",
+  "iconfield",
+  "iftalabel",
+  "image",
+  "imagecompare",
+  "inplace",
+  "inputgroup",
+  "inputmask",
+  "inputnumber",
+  "inputotp",
+  "inputtext",
+  "keyfilter",
+  "knob",
+  "listbox",
+  "llms",
+  "mcp",
+  "megamenu",
+  "menu",
+  "menubar",
+  "message",
+  "metergroup",
+  "multiselect",
+  "orderlist",
+  "organizationchart",
+  "paginator",
+  "panel",
+  "panelmenu",
+  "passthrough",
+  "password",
+  "picklist",
+  "popover",
+  "progressbar",
+  "progressspinner",
+  "radiobutton",
+  "rating",
+  "ripple",
+  "scrollpanel",
+  "scrolltop",
+  "select",
+  "selectbutton",
+  "skeleton",
+  "slider",
+  "speeddial",
+  "splitbutton",
+  "splitter",
+  "stepper",
+  "styleclass",
+  "table",
+  "tabs",
+  "tag",
+  "terminal",
+  "textarea",
+  "tieredmenu",
+  "timeline",
+  "toast",
+  "togglebutton",
+  "toggleswitch",
+  "toolbar",
+  "tooltip",
+  "tree",
+  "treeselect",
+  "treetable",
+  "virtualscroller"
+]
    • Changedget_component_examples1 field changed
      • changedInput schema / properties / component / enum
        Previous value: -[
-  "accordion",
-  "animateonscroll",
-  "autocomplete",
-  "autofocus",
-  "avatar",
-  "badge",
-  "bind",
-  "blockui",
-  "breadcrumb",
-  "button",
-  "card",
-  "carousel",
-  "cascadeselect",
-  "checkbox",
-  "chip",
-  "colorpicker",
-  "confirmdialog",
-  "confirmpopup",
-  "contextmenu",
-  "dataview",
-  "datepicker",
-  "dialog",
-  "divider",
-  "dock",
-  "drawer",
-  "dynamicdialog",
-  "editor",
-  "fieldset",
-  "fileupload",
-  "floatlabel",
-  "fluid",
-  "focustrap",
-  "galleria",
-  "iconfield",
-  "iftalabel",
-  "image",
-  "imagecompare",
-  "inplace",
-  "inputgroup",
-  "inputmask",
-  "inputnumber",
-  "inputotp",
-  "inputtext",
-  "keyfilter",
-  "knob",
-  "listbox",
-  "megamenu",
-  "menu",
-  "menubar",
-  "message",
-  "metergroup",
-  "multiselect",
-  "orderlist",
-  "organizationchart",
-  "paginator",
-  "panel",
-  "panelmenu",
-  "passthrough",
-  "password",
-  "picklist",
-  "popover",
-  "progressbar",
-  "progressspinner",
-  "radiobutton",
-  "rating",
-  "ripple",
-  "scrollpanel",
-  "scrolltop",
-  "select",
-  "selectbutton",
-  "skeleton",
-  "slider",
-  "speeddial",
-  "splitbutton",
-  "splitter",
-  "stepper",
-  "styleclass",
-  "table",
-  "tabs",
-  "tag",
-  "terminal",
-  "textarea",
-  "tieredmenu",
-  "timeline",
-  "toast",
-  "togglebutton",
-  "toggleswitch",
-  "toolbar",
-  "tooltip",
-  "tree",
-  "treeselect",
-  "treetable",
-  "virtualscroller"
-]New value: +[
+  "accordion",
+  "animateonscroll",
+  "autocomplete",
+  "autofocus",
+  "avatar",
+  "badge",
+  "bind",
+  "blockui",
+  "breadcrumb",
+  "button",
+  "card",
+  "carousel",
+  "cascadeselect",
+  "checkbox",
+  "chip",
+  "colorpicker",
+  "confirmdialog",
+  "confirmpopup",
+  "contextmenu",
+  "dataview",
+  "datepicker",
+  "dialog",
+  "divider",
+  "dock",
+  "drawer",
+  "dynamicdialog",
+  "editor",
+  "fieldset",
+  "fileupload",
+  "floatlabel",
+  "fluid",
+  "focustrap",
+  "galleria",
+  "iconfield",
+  "iftalabel",
+  "image",
+  "imagecompare",
+  "inplace",
+  "inputgroup",
+  "inputmask",
+  "inputnumber",
+  "inputotp",
+  "inputtext",
+  "keyfilter",
+  "knob",
+  "listbox",
+  "llms",
+  "mcp",
+  "megamenu",
+  "menu",
+  "menubar",
+  "message",
+  "metergroup",
+  "multiselect",
+  "orderlist",
+  "organizationchart",
+  "paginator",
+  "panel",
+  "panelmenu",
+  "passthrough",
+  "password",
+  "picklist",
+  "popover",
+  "progressbar",
+  "progressspinner",
+  "radiobutton",
+  "rating",
+  "ripple",
+  "scrollpanel",
+  "scrolltop",
+  "select",
+  "selectbutton",
+  "skeleton",
+  "slider",
+  "speeddial",
+  "splitbutton",
+  "splitter",
+  "stepper",
+  "styleclass",
+  "table",
+  "tabs",
+  "tag",
+  "terminal",
+  "textarea",
+  "tieredmenu",
+  "timeline",
+  "toast",
+  "togglebutton",
+  "toggleswitch",
+  "toolbar",
+  "tooltip",
+  "tree",
+  "treeselect",
+  "treetable",
+  "virtualscroller"
+]
  2. 9 tool updates
    • First observedgenerate_component_code
    • First observedget_component_doc
    • First observedget_component_examples
    • First observedget_icons_guide
    • First observedget_installation_guide
    • First observedget_tailwind_guide
    • First observedget_theming_guide
    • First observedlist_all_components
    • First observedsearch_components
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: generate_component_code creates code, get_component_doc retrieves documentation, get_component_examples shows usage examples, get_icons_guide covers icons, get_installation_guide handles setup, get_tailwind_guide focuses on Tailwind integration, get_theming_guide addresses theming, list_all_components enumerates components, and search_components finds components. The boundaries are well-defined, preventing confusion.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case: generate_component_code, get_component_doc, get_component_examples, get_icons_guide, get_installation_guide, get_tailwind_guide, get_theming_guide, list_all_components, and search_components. The naming is predictable and readable throughout, with no deviations in style or convention.

Tool Count5/5

With 9 tools, the count is well-scoped for a PrimeNG documentation and code generation server. Each tool earns its place by covering distinct aspects like documentation retrieval, examples, guides, and component listing/searching. This is neither too sparse nor bloated, fitting typical server scopes of 3-15 tools.

Completeness5/5

The tool set provides complete coverage for the PrimeNG domain, including CRUD-like operations for components (list, search, get docs/examples), code generation, and comprehensive guides (installation, theming, icons, Tailwind). There are no obvious gaps; agents can access all necessary information and functionality without dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

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/hnkatze/PrimeNG_MCP'

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