Provides validation and optimization for Anime.js v4 code using the Three.js adapter, including degree conversion for rotation/skew, vector axis splitting (normalScaleX/Y), TSL NodeMaterial support, bare UniformNodes, and warnings about shared materials, Group targets, and unsupported uniform types.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Anime.js v4 Expert Server validate this anime({targets: '.box'}) code and suggest v4 fixes"
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.
Servidor oficial para el Model Context Protocol (MCP) diseñado para asistir a desarrolladores e Inteligencias Artificiales en el uso correcto, moderno y optimizado de Anime.js v4.
Cuenta con una cobertura completa del 100% de la documentación técnica oficial de Anime.js v4, 389 módulos de catálogo técnico, más de 70.000 líneas de conocimiento indexado y 395 pruebas automatizadas.
Auditoría y Validación AST en tiempo real (validate_anime_code):
Detección de sintaxis v3 obsoleta: anime({ targets }), anime.timeline(), begin, update, complete, etc., con sugerencias automáticas de reemplazo hacia v4 (animate(), createTimeline(), callbacks onBegin, onUpdate, etc.).
Optimización de Rendimiento: Alerta sobre propiedades causantes de Reflow / Layout Thrashing (top, left, width, height) y recomienda transformaciones GPU aceleradas (x, y, scale, rotate).
Detección de Fugas de Memoria: Advierte en componentes React/Vue si falta la reversión (scope.revert() o timer.revert()).
Soporte Completo del Adaptador Three.js: Valida conversión automática de grados en rotation/skew, partición de ejes vectoriales (normalScaleX/Y), soporte TSL NodeMaterial, bare UniformNodes, y advertencias pedagógicas sobre materiales compartidos, targets Group y tipos de uniformes fuera de alcance (Matrix, Texture).
Score de Salud (0-100): Proporciona diagnósticos con nivel de severidad (error, warning, info) y código de sugerencia (fixSuggestion).
Base Documental Exhaustiva y Búsqueda Semántica (search_anime_docs):
Más de 70.000 líneas documentales con especificaciones técnicas detalladas y snippets oficiales canónicos.
Búsqueda difusa y semántica por conceptos: spring, stagger, timeline, waapi, threejs, layout, flip, scope, timeUnit, etc.
Catálogo de Parámetros del Motor (get_parameter_details):
Información técnica profunda sobre todos los parámetros de animación, reproducción, temporizadores y motor global (engine.defaults, engine.speed, engine.fps, engine.timeUnit).
Guías Oficiales Integradas:
Migración v3 ➡️ v4 (get_migration_guide): 23 reglas de migración con tabla de equivalencias y ejemplos de antes/después.
Instalación (get_installation_guide): Recomendación prioritaria de Bun (bun add animejs), además de NPM, PNPM, CDN ESM/UMD y descargas GitHub.
Subrutas Granulares (get_subpaths_directory): 14 subpaths oficiales (animejs/animation, timer, timeline, adapters/three, waapi, layout, etc.) con generador de <script type="importmap">.
Recursos MCP (animejs://v4/...):
Más de 100 recursos URI Markdown para lectura directa de guías de animación, temporizadores, layouts FLIP, física inercial de arrastre, SVG motion path, Web Animations API y Three.js.
Related MCP server: Config MCP Server
Herramienta | Descripción |
| Analiza código JavaScript/TypeScript/JSX y emite diagnóstico AST con puntaje de salud (0-100), advertencias y sugerencias automáticas. |
| Motor de búsqueda documental y catálogo semántico en toda la base de conocimientos oficial. |
| Especificación técnica, tipos, valores válidos, defaults y avisos de reflow de cualquier parámetro. |
| Catálogo de las 23 reglas de migración oficiales de Anime.js v3 a v4 con ejemplos de equivalencia. |
| Guía de instalación y configuración en Bun, NPM, PNPM, CDN y browsers modernos. |
| Directorio de las 14 subrutas granulares para Tree Shaking e Import Maps nativos. |
Añade a tu archivo de configuración claude_desktop_config.json:
{
"mcpServers": {
"animejs-v4": {
"command": "npx",
"args": ["-y", "github:Padalogu/mcp-animejs-v4"]
}
}
}O apuntando a tu clon local:
{
"mcpServers": {
"animejs-v4": {
"command": "node",
"args": ["/ruta/absoluta/a/mcp-animejs-v4/dist/index.js"]
}
}
}.cursor/mcp.json){
"mcpServers": {
"animejs-v4": {
"command": "node",
"args": ["/ruta/absoluta/a/mcp-animejs-v4/dist/index.js"]
}
}
}~/.gemini/config/mcp_config.json){
"mcpServers": {
"animejs-v4": {
"command": "node",
"args": [
"/home/padalogu/Proyectos/Padavertex/mcp-animejs-v4/dist/index.js"
]
}
}
}git clone https://github.com/Padalogu/mcp-animejs-v4.git
cd mcp-animejs-v4
npm install
npm run build
npm linkAhora puedes ejecutar el servidor directamente en la terminal o integrarlo como:
mcp-animejs-v4El proyecto cuenta con una suite completa de 395 pruebas automatizadas que validan la exactitud de los diagnósticos AST, snippets oficiales y catálogo:
# Ejecutar la suite completa de 395 pruebas
npm test
# Compilar TypeScript
npm run buildMIT © Padalogu
Agrega o actualiza un artículo o guía técnica en la documentación de Anime.js v4.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Identificador único del artículo | |
| tags | Yes | Etiquetas clave | |
| title | Yes | Título del artículo | |
| content | Yes | Contenido completo en Markdown | |
| summary | Yes | Resumen breve | |
| category | Yes | Categoría del artículo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. For a mutation tool (add/update) with no output schema, the description should disclose effects: does it overwrite on duplicate id, require specific permissions, validate content, or return a confirmation? None of this is stated. 'Agrega o actualiza' hints at upsert behavior but without specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with no wasted words. The purpose is front-loaded. Appropriate length for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with no annotations and no output schema, the description is too thin. It lacks behavioral details, usage context, and differentiations from siblings. An agent can identify the action but lacks enough context to call it confidently in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is documented in the schema. The description does not add meaning beyond the schema. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: adds or updates a technical article/guide in Anime.js v4 documentation. Distinguishes from siblings implicitly (writes to docs vs. reads/search/validate). However, no explicit sibling naming, and the object 'documentación de Anime.js v4' is somewhat broad compared to specific siblings like get_migration_guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance. The description does not mention prerequisites, alternatives, or how this relates to sibling tools such as validate_anime_code or search_anime_docs. An agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene las instrucciones y comandos de instalación de Anime.js v4. Recomienda Bun como gestor principal por velocidad y tipado nativo, e incluye opciones para NPM, PNPM, Yarn, CDN (esm.sh/jsDelivr) y descarga directa.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Método de instalación específico (opcional, si se omite devuelve todas las opciones destacando Bun). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden. It discloses the content and the Bun-default behavior, but does not state that this is a safe read-only retrieval, nor anything about return format, size, or caching. For a documentation-fetch tool this is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with no filler; the purpose and the Bun recommendation are front-loaded, and no sentence is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter tool with no output schema, the description adequately conveys what will be returned (instructions/commands plus all install methods). It is complete enough to invoke correctly, with only minor gaps around result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the enum values and the default-when-omitted behavior are already fully documented in the schema. The description adds no parameter syntax or format detail beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (obtiene) and resource (instrucciones y comandos de instalación) scoped to Anime.js v4, and enumerates the covered installation methods. It is clear what the tool delivers, though it does not explicitly distinguish itself from the nearby get_module_imports_guide sibling, which overlaps conceptually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (fetch installation instructions for Anime.js v4), and the schema note clarifies that omitting 'method' returns all options with Bun highlighted. However, no explicit when-to-use/when-not-to-use guidance or routing to alternative siblings (e.g. get_module_imports_guide) is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta la guía oficial y tabla de equivalencias para migrar código de Anime.js v3 a v4 (parámetros renombrados, métodos reemplazados, callbacks, promesas, SVG y helpers).
| Name | Required | Description | Default |
|---|---|---|---|
| feature | No | Buscar por nombre de propiedad o característica (ej. 'endDelay', 'easing', 'direction', 'timeline', 'path', 'round', 'change', 'finished'). | |
| category | No | Categoría específica de migración a consultar (opcional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the guide's scope (renamed params, replaced methods, callbacks, promises, SVG, helpers) but omits return format, whether it is read-only, and how filtering affects output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core purpose and adds a compact parenthetical list of covered topics. Every element earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple documentation lookup with two optional, fully described parameters and no nested objects, the description is largely complete. It could still state the return format or how feature/category filtering behaves, but the core context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the 'feature' and 'category' parameters are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (consulta) and resource (guía oficial y tabla de equivalencias) for migrating Anime.js v3 to v4, and enumerates covered topics. It clearly distinguishes the tool's migration focus, though it does not explicitly contrast with siblings like search_anime_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for migrating Anime.js v3 code to v4, which is a clear context. However, it offers no explicit when-to-use/when-not guidance or mention of alternative tools, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta las opciones de importación modular de Anime.js v4: desde el módulo principal 'animejs', importación granular por subpaths (animejs/animation, animejs/timer, animejs/text, animejs/draggable, etc.) o importmaps para navegadores.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Buscar de qué subpath importar una función o exportación concreta (ej. 'splitText', 'createTimer', 'createDraggable', 'stagger', 'createSpring'). | |
| subpath | No | Nombre de subpath específico (ej. 'animejs/animation', 'animejs/text', 'animejs/timer', 'animejs/utils'). | |
| generateImportMap | No | Generar el snippet HTML <script type="importmap"> completo para usar Anime.js v4 en navegadores sin build step. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the content it returns (import options, subpaths, importmap snippets), but never states that this is a non-destructive read-only lookup, whether it reflects a pinned Anime.js version, or how the answer is shaped. Adequate but with clear gaps for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that lists the three import strategies with concrete examples. Efficient and readable, with only minor redundancy against the schema's own examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All three parameters are optional and there is no output schema, so the description needn't explain return values. For a simple read-only reference tool the coverage is essentially sufficient, with only the read-only/no-side-effect reassurance missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all three parameters with their own examples, and the baseline is 3. The description restates the same subpath and importmap concepts at a high level but adds no new syntax, format, or interaction detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Consulta las opciones de importación modular de Anime.js v4') and enumerates the three modes of import it covers: main module, granular subpaths, and importmaps. An agent can tell it is a reference/lookup tool, though it never explicitly contrasts itself with the nearby get_installation_guide or get_migration_guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the topic — reach for it when you need to know how to import a given piece of Anime.js v4. However, there is no explicit when-to-use framing and no mention of when a sibling such as get_installation_guide or search_anime_docs would be the better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene información técnica detallada, tipo, valores por defecto, ejemplos y notas de rendimiento de un parámetro específico del motor.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nombre del parámetro (ej. 'duration', 'ease', 'composition', 'playbackRate', 'x', 'scale'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the kinds of information returned (technical details, type, defaults, examples, performance notes) and 'Obtiene' implies a read-only lookup, but it does not explicitly state side effects, permissions, or rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently packs the return content categories without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one documented parameter and no output schema, the description is largely complete: it says what will be returned. It falls short only by not routing the agent to alternatives for discovering parameter names or validating them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter and schema description coverage is 100%, so the schema already documents the 'name' parameter including examples. The description adds no syntax, format, or naming constraints beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Obtiene') and resource ('información técnica detallada ... de un parámetro específico del motor'). The phrase 'un parámetro específico' distinguishes it from the sibling 'list_engine_parameters', which would enumerate parameters rather than detail one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this when you already know the name of a specific engine parameter and need details about it. However, the description does not explicitly say when to use this versus siblings such as 'list_engine_parameters', 'validate_anime_code', or 'register_parameter'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los parámetros conocidos del motor Anime.js v4, opcionalmente filtrados por categoría.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Categoría opcional para filtrar los parámetros. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Lista' implies a non-destructive read, but it says nothing about ordering, completeness (what makes a parameter 'conocido'), or required permissions, and gives no sense of the returned entries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the action, the resource, the version scope, and the optional filter. Nothing extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-param list tool with no annotations it is adequate, but with no output schema the description should sketch what a listed parameter looks like (name, category, description?) to let an agent use the result without a follow-up probe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the enum is fully enumerated in the schema, so baseline 3 applies. The description confirms the category filter is optional but adds no semantics (e.g., whether omitting it returns everything) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Lista los parámetros conocidos del motor Anime.js v4'. An agent can distinguish this from get_parameter_details or search_anime_docs by the listing/enumeration nature, though it never explicitly names a sibling or contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'opcionalmente filtrados por categoría' implies you can call it bare for a full dump or narrow it by category, but there is no explicit when-to-use guidance or routing to get_parameter_details for deeper info on a single parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registra o actualiza dinámicamente un parámetro en el catálogo del motor Anime.js v4.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nombre del parámetro | |
| tips | No | Consejos y notas de rendimiento | |
| type | Yes | Tipo de dato en TypeScript (ej. 'number | string') | |
| category | Yes | ||
| examples | Yes | Ejemplos de uso | |
| description | Yes | Descripción detallada del parámetro | |
| causesReflow | No | Indica si causa recálculo de diseño (reflow) | |
| defaultValue | No | Valor predeterminado | |
| versionAdded | Yes | Versión en la que se introdujo (ej. 'v4.0.0') | |
| isGpuAccelerated | No | Indica si la propiedad es acelerada por GPU |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says the registration is 'dynamic' but does not disclose what happens on name collision (overwrite vs error), whether required fields cause validation failure, whether changes persist, or whether the catalog is shared/mutated globally. For a mutation tool with zero annotation coverage, this is a real gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no redundancy. It is terse but every word counts; however it is arguably under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 6 of them required, no annotations, and no output schema, the one-sentence description is inadequate. It omits collision behavior, permission/auth needs, and the effect on the live engine, which an agent needs before invoking a catalog-mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 90%, so the schema already documents nearly every field, and the required/enum structure is clear. The description adds no semantic detail about any parameter (e.g., the versionAdded format or category enum usage), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair (registers/updates) and a specific resource (a parameter in the Anime.js v4 engine catalog). It is distinguishable from read-oriented siblings like list_engine_parameters and get_parameter_details, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this tool versus add_custom_doc, get_parameter_details, or list_engine_parameters. No prerequisites or exclusions are given; the agent must infer that this is a write path from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca en la base de conocimiento y catálogo de Anime.js v4 por términos clave (ej. 'spring', 'timeline', 'stagger', 'memory', 'x', 'composition').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Término de búsqueda o concepto a consultar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only names the search scope. It says nothing about ranking, result limits, whether queries are literal or semantic, or what a no-match response looks like. For a retrieval tool this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the action and target stated first, followed by parenthetical examples. The example list is somewhat long but each item clarifies the query granularity, so it largely earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with no annotations and no output schema, the description covers scope and query style but omits anything about returned results or failure behavior. It is minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds genuine value beyond the schema by giving concrete example terms ('spring', 'timeline', 'stagger', 'memory', 'x', 'composition') that demonstrate the expected granularity of the query string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Busca') and resource ('base de conocimiento y catálogo de Anime.js v4'), so the agent knows this is a keyword lookup over documentation. It does not explicitly contrast itself with siblings like get_parameter_details or list_engine_parameters, but the search-vs-fetch distinction is reasonably inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent can guess this is the tool to reach for when it doesn't know the exact doc entry, but the description never says when to prefer it over get_parameter_details, get_migration_guide, or the other sibling getters. The example keywords hint at intent but are not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Valida un fragmento de código JavaScript/TypeScript usando AST para detectar sintaxis obsoleta de v3, propiedades que causan reflow/layout-thrashing y fugas de memoria en frameworks.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Código fuente de JavaScript, TypeScript o JSX que contiene animaciones de Anime.js. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states what the tool detects via AST but omits critical behavioral traits: whether it requires imported dependencies, how it handles invalid input, whether it returns errors or warnings with line numbers, performance/rate limits on large files, or whether analysis is static-only. For a validation tool with zero annotation coverage, these gaps are significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Valida un fragmento de código JavaScript/TypeScript usando AST') and then enumerates the specific issues detected. Every clause earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with one required parameter, no output schema, and no annotations, the description is incomplete. It does not explain what the validation returns (errors, warnings, severity levels), how to interpret results, whether validation is syntactic or semantic beyond the listed checks, or any prerequisites (e.g., anime.js version context). The agent lacks enough information to use the tool confidently or interpret its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single 'code' parameter is fully documented in the schema as 'Código fuente de JavaScript, TypeScript o JSX que contiene animaciones de Anime.js.' The description adds no further detail about the parameter's expected format, size limits, or handling of non-Anime.js code. Per rules, high schema coverage yields a baseline 3 when the description adds nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Valida') and resource ('fragmento de código JavaScript/TypeScript usando AST'), and enumerates exactly what it detects: v3-obsolete syntax, reflow/layout-thrashing properties, and memory leaks. This clearly distinguishes it from documentation-oriented siblings like search_anime_docs or get_migration_guide. However, it does not explicitly name the sibling alternative for validation tasks, keeping it just below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to validate code for v3 syntax, reflow issues, or memory leaks) but provides no explicit when-to-use vs when-not-to-use guidance, no alternatives, and no note about applicable framework contexts. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0add_custom_docget_installation_guideget_migration_guideget_module_imports_guideget_parameter_detailslist_engine_parametersregister_parametersearch_anime_docsvalidate_anime_codeScored across 9 tools
Most tools target clearly distinct purposes: validation, doc search, parameter lookup (get vs list), migration, install, imports, and two write operations. The main overlap is between search_anime_docs and the specific get_*_guide tools, since a keyword search could surface the same migration/install/import content, but the descriptions give enough separation to disambiguate.
All tools use a consistent snake_case verb_noun pattern (validate_anime_code, get_parameter_details, list_engine_parameters, register_parameter, add_custom_doc). The verbs vary appropriately (get/list/search/validate/register/add) but the structure is entirely predictable.
Nine tools is well-scoped for an expert domain server, covering lookup, validation, and documentation management without bloat. Each tool serves a distinct function with no redundancy.
Strong coverage of the domain: read (search/get/list), write (register_parameter, add_custom_doc), validation, and migration/install/import guidance. Minor gaps include no delete/remove counterpart for registered parameters or custom docs, and no automated code-fix tool, but core lifecycle is covered.
The official Svelte MCP server providing docs and autofixing tools for Svelte development
Get up-to-date, version-specific documentation and code examples from official sources directly in…
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.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
