Guías en español de PLC Siemens y TIA Portal: busca y lee +330 tutoriales (SCL, LADDER, AWL, HMI).
Scored across 6 tools
Each tool targets a distinct resource or filter: author, categories, individual post, latest posts, category posts, and search. The only possible confusion is among the three tools that return lists of posts, but their descriptions are clear enough to guide selection.
All tool names use lowercase snake_case with a verb + noun structure, which is consistent and readable. However, get_ is used for both singular and collection-returning tools, while list_ appears only on list_categories and search_posts uses a different verb, creating minor inconsistency.
Six tools is a well-scoped size for a blog/content server. Each tool covers a distinct need without redundancy, and the number feels neither too thin nor too heavy.
The toolset covers the core read-model of a blog: author info, categories, latest posts, category filtering, search, and full post retrieval. The main gap is the lack of course-specific tools despite the server name mentioning courses, though courses may be represented as blog articles.
Bio y credenciales del instructor Iñigo Gútiez.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful content-level transparency by specifying that the tool returns biographical and credential information, which goes beyond the annotations.
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 sentence that directly states the essential information. There is no filler, redundancy, or unnecessary detail.
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?
Given the tool's simplicity, no parameters, and read-only annotations, the description provides sufficient context for an agent to understand what the tool returns. It could be slightly more explicit about output format, but the high-level content description is adequate.
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?
The tool has zero parameters and the schema is fully covered with 100% description coverage, so there is nothing for the description to add. Baseline 4 is appropriate for a parameterless tool.
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 clearly identifies the resource (instructor Iñigo Gútiez) and the content returned (bio and credentials). It is distinguishable from sibling tools like get_post and get_course by focusing on the author/instructor, though it lacks an explicit action verb like 'returns'.
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 usage context is implied: use this tool when you need the instructor's bio or credentials. However, it does not explicitly say when to choose it over sibling tools such as get_course or get_curriculum, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los artículos de una categoría del blog.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug de la categoría | |
| limit | No | Máximo de resultados |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the read-only listing behavior but does not disclose ordering, default limit, or pagination behavior. This is acceptable for a simple list tool, but no additional behavioral context is provided beyond what annotations and the schema already imply.
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 concise sentence that directly names the operation and resource. It contains no filler or redundant phrasing, and it is front-loaded with the key action 'Lista los artículos'.
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 list endpoint with two well-documented parameters and no output schema, the description is nearly sufficient. It tells the agent what the tool returns (articles of a category) and the annotations cover safety. Minor missing context such as result ordering or default pagination does not prevent correct invocation.
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 schema already documents both 'slug' and 'limit' with types, constraints, and descriptions. The tool description does not add extra meaning about the parameters, so the baseline of 3 is 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?
The description clearly states a specific verb and resource: 'Lista los artículos de una categoría del blog.' This distinguishes it from single-post retrieval like get_post and from latest-posts listing like get_latest_posts. It does not explicitly contrast itself with search_posts, but the category-scoped resource is clear enough.
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 when to use this tool: when you need articles belonging to a category. However, it gives no explicit guidance about when not to use it or which alternative tool to choose (e.g., search_posts for full-text search or get_latest_posts for recent posts). The context is clear but the exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los artículos más recientes del blog.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Máximo de resultados (por defecto 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
La descripción coincide con readOnlyHint=true y destructiveHint=false al indicar que solo lista contenido, aportando el matiz de orden temporal. No añade detalles sobre formato de respuesta, paginación ni límite por defecto, aunque las anotaciones ya cubren el perfil de seguridad.
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?
Una sola oración con el verbo y el objeto al inicio, sin relleno ni repeticiones. El tamaño es proporcional a la simplicidad de la herramienta.
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?
Para una herramienta de solo lectura con un parámetro opcional y sin output schema, la descripción junto con el schema cubren lo esencial: qué hace y cuántos resultados admite. No explica la forma exacta de la respuesta, pero el verbo 'Lista' y las anotaciones hacen que sea suficiente para un uso básico.
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?
El único parámetro, limit, está totalmente documentado en el input schema con mínimo, máximo y valor por defecto (10). Con una cobertura de esquema del 100%, la descripción no necesita aportar nada adicional y no lo hace.
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?
La descripción comienza con el verbo 'Lista' y especifica el recurso 'artículos más recientes del blog', lo que permite distinguirla de get_post (un post concreto), search_posts (búsqueda) y get_category_posts (por categoría). El alcance 'más recientes' es preciso y no presenta ambigüedad.
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?
El uso queda implícito: quien necesite los artículos recientes del blog debe usar esta herramienta. Sin embargo, no se mencionan exclusiones ni alternativas, por ejemplo que search_posts sirve para búsqueda por texto o get_post para un artículo específico.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lee un artículo del blog en Markdown por su slug. Permite paginar artículos largos con offset y limit.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug del post, ej: 'el-poder-del-scl' | |
| limit | No | Caracteres máximos a devolver (por defecto 8000, máximo 20000) | |
| offset | No | Posición inicial en caracteres (por defecto 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only safety, so the description only needs to add behavioral context. It adds that output is Markdown and that offset/limit paginate long articles, which is genuinely useful. It does not cover not-found behavior, but that is a minor gap for a simple read.
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 sentences with no filler: the first declares purpose, the second adds pagination behavior. The essential information is front-loaded.
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 read-only tool with one required parameter and a fully described schema, the description is nearly complete: it names the return format and pagination behavior. The only real omission is routing guidance among siblings, already penalized under usage guidelines.
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 schema already fully documents slug, limit, and offset with defaults and ranges. The description's pagination phrase just restates what the schema conveys, adding no extra parameter semantics.
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 opens with a specific verb and resource: 'Lee un artículo del blog en Markdown por su slug'. It names the identifier (slug), the output format (Markdown), and makes clear this targets one article, distinguishing it from sibling list/search tools even without naming 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?
There is no guidance about when to prefer get_post over get_latest_posts, get_category_posts, or search_posts. The pagination sentence describes a feature but not selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las categorías del blog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to re-state safety. It adds no extra behavioral context (e.g., ordering, completeness, response format), so a mid score is appropriate.
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, compact sentence that is clear and front-loaded. Every word earns its place, with no filler.
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 zero-parameter, read-only listing tool, the description states what is listed. It does not detail return format or pagination, but given the simple use case and lack of an output schema, it is mostly 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?
The tool has 0 parameters, so the baseline is 4. The description does not need to document parameters because there are none.
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 ('Lista') and a specific resource ('las categorías del blog'), clearly stating the tool's function. It is distinct from all siblings, none of which list categories.
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?
There is no explicit guidance on when to use this tool vs alternatives, but the purpose is self-evident: retrieving all blog categories. The intended usage is implied rather than stated, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca artículos del blog de Programación Siemens por tema (TIA Portal, SCL, AWL, PROFINET, HMI, PLC Siemens...).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Máximo de resultados (por defecto 10) | |
| query | Yes | Término de búsqueda |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds useful context by enumerating example topics, which clarifies the scope of what is searchable. It doesn't mention return format or ordering, but the annotations lower the bar for behavioral disclosure. No contradiction with annotations.
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 efficiently conveys the tool's purpose and scope. Zero filler; every word contributes to the agent's understanding. Excellent structure.
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 read-only search tool with annotations covering safety, the description is adequate. It does not specify the exact return format (e.g., list of posts), but that is commonly inferred and not strictly required for invocation. The limit parameter and topic examples cover most usage needs. Minor gap: no mention of sorting or pagination behavior, but not critical for a simple search.
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% and the schema already documents both parameters (query and limit). The description adds value by providing example topics (TIA Portal, SCL, etc.) that help the agent understand what to put in the query parameter beyond the generic 'término de búsqueda'. This is meaningful supplemental meaning.
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 ('Busca' = search), resource ('artículos del blog de Programación Siemens'), and scope (by topic), with concrete examples. It clearly distinguishes from siblings like get_post (specific post) and get_latest_posts (recent posts) by emphasizing topic-based search.
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 provides clear context that this tool is for searching blog articles by topic (e.g., TIA Portal, SCL), making it the obvious choice for keyword/topic queries. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to distinguish it from category browsing or fetching specific posts.
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.
get_courseget_curriculumsearch_coursesget_buy_urlget_category_posts6 fields changedInput schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / slug / maxLengthAdded value: +200Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9]+(?:-[a-z0-9]+)*$"get_course3 fields changedInput schema / properties / slug / maxLengthAdded value: +200Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9]+(?:-[a-z0-9]+)*$"get_curriculum3 fields changedInput schema / properties / slug / maxLengthAdded value: +200Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9]+(?:-[a-z0-9]+)*$"get_latest_posts3 fields changedInput schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"get_post5 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Caracteres máximos a devolver (por defecto 8000, máximo 20000)",
+ "maximum": 20000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Posición inicial en caracteres (por defecto 0)",
+ "maximum": 1000000,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / slug / maxLengthAdded value: +200Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9]+(?:-[a-z0-9]+)*$"search_courses1 field changedInput schema / properties / query / maxLengthAdded value: +200search_posts5 fields changedInput schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / query / maxLengthAdded value: +200Input schema / properties / query / minLengthAdded value: +1get_authorget_buy_urlget_category_postsget_courseget_curriculumget_latest_postsget_postlist_categoriessearch_coursessearch_postsIndustrial glossary, protocol reference, technical search and OEE calculation. Read-only.
Query Allen-Bradley and Siemens PLC projects, live tag values, and analyses in plain English.
Subvenciones, licitaciones y boletines oficiales de España y Europa para tu IA. Gratis, sin login.
Resultados, botes, reglas y comprobación de premios de las loterías del Estado (España).
Add one secure layer between your agents and this server.
