bpmn-generator-mcp

by johnleyva28

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0-typescript
Disambiguation3/5
Many tools are clearly distinct, but the set includes several overlapping reference/catalog tools (e.g., get_flow_elements_catalog vs list_bpmn_elements, get_activities_catalog vs get_task_types_info) and closely related creation variants (e.g., create_process_with_boundary_events vs create_process_with_error_handling). Descriptions help, but an agent could easily select the wrong lookup or generator in a 41-tool surface.
Naming Consistency4/5
Tool names consistently use snake_case and mostly follow a verb_noun pattern, which is predictable. Minor deviations exist, such as create_from_yaml_spec vs create_process_from_text_description vs create_simple_linear_process, but the overall style remains coherent.
Tool Count2/5
With 41 tools, the server is over-scoped for most agent workflows. The many catalog/reference/lookup tools could be consolidated into a smaller set, and the proliferation of create_process_with_* variants adds unnecessary bulk.
Completeness4/5
The server covers BPMN generation well: multiple construction patterns, validation, templates, catalogs, OCR input, and output file access. Minor gaps exist around updating/deleting generated files or directly editing existing BPMN models, but these are not core to a generator's main workflow.
Average 3/5 across 41 of 41 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of disclosing behavior. It does not state whether the tool returns a list, a structured reference, or something else, nor does it mention side effects, output format, or any operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of fluff, but it is under-specified to the point of being unhelpful. It reads more like a missing description than a deliberately concise one.
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?
There is no output schema or annotations, and the description does not say what the catalog contains, how it should be used, or how it differs from several similarly named sibling catalogs. This leaves the agent without enough context to select or invoke the tool correctly.
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 input schema has zero parameters and the description coverage is 100%, so there are no parameter semantics to clarify. The description adds nothing about inputs, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
"Catálogo de atributos BPMN 2.0" essentially restates the tool name as a noun phrase rather than stating a concrete action. It identifies a subject area but provides no verb or function, and it does not distinguish this catalog from closely related sibling catalogs like get_activities_catalog or get_flow_elements_catalog.
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 gives no guidance about when to use this tool or when to choose one of the many sibling catalogs instead. There is no mention of use cases, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 reveals nothing about side effects, output shape, scope, or whether this is read-only; it only states a topic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It is a fragment, not a complete sentence, and does not earn its place as a functional tool description.
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?
While the tool has no parameters and no output schema, the sparse description leaves the agent unable to know what kind of content will be returned, how it is organized, or how it differs from the large set of sibling information tools.
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 the schema is empty, so there is nothing for the description to clarify. The baseline for zero-parameter tools applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Best practices BPMN 2.0." is a noun phrase that merely restates the tool name and subject matter; it lacks a verb such as 'retrieve' or 'list'. It also does not distinguish itself from nearby sibling tools like get_validation_rules, get_bpmn_cheatsheet, or explain_bpmn_concept.
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?
There is no guidance on when to use this tool versus any of the many related informational tools in the sibling list. The description provides no context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it reveals almost nothing about behavior. It does not describe the returned content, operational constraints, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the brevity reflects under-specification rather than effective conciseness. The phrase adds little value and is not structured in a way that helps an agent understand what the tool actually provides.
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?
With no output schema and no annotations, the description needed to explain what 'extended information' means and what the agent will receive. It does neither, leaving the tool ambiguous among many sibling reference and catalog tools.
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 input schema has zero parameters, so there are no parameter semantics for the description to clarify. The zero-parameter baseline is 4, and no schema coverage gap exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Información extendida de Bizagi Modeler' is essentially a translation of the tool name, so it restates rather than explains. It does not specify what information is included and does not distinguish the tool from siblings such as get_bizagi_specifics or get_bpmn_cheatsheet.
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?
There is no guidance on when to call this tool instead of any of the many sibling information or catalog tools. The description implies that it returns information but provides no use cases, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only offers 'Agrega' (adds). It does not state whether the tool mutates an in-memory process model, creates and returns a new process, what side effects occur, or how the parameters shape the resulting BPMN, leaving the operation's consequences opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence is easy to parse and wastes no words. However, the brevity is under-specification rather than efficient completeness—it omits trigger semantics, parameter meaning, and usage context.
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 tool with three untyped parameters, no output schema, no annotations, and a dense sibling landscape, this description is insuffcient. It omits the trigger behavior implied by the name, the meaning of every parameter, and the relationship to close siblings like create_process_with_timer and create_process_with_boundary_events, so an agent cannot reliably construct a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: all three parameters (attached_to_ref, timer_definition, condition_expression) are untyped shells with no schema descriptions, and the tool description does not compensate by explaining any of them. An agent gets no help inferring that attached_to_ref likely targets a boundary-event anchor or that timer_definition/condition_expression are the 'trigger' payload, so parameter semantics are effectively undocumented.
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 names a specific verb and resource ('Agrega un evento') and enumerates the four event types (start/intermediate/end/boundary), so the core action is clear and not confusable with validation/creation/reading siblings. However, it never mentions the 'trigger' behavior implied by the tool name, and 'a un proceso nvevo' is ambiguous—it could mean the event is added while creating a new process, which slightly blurs the boundary against create_process_with_timer and create_process_with_boundary_events.
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 when-to-use guidance is provided. The description does not say whether this tool is a building block to call after create_simple_linear_process, whether it substitutes for create_process_with_timer, or what conditions select it over the many event-related siblings, so an agent has no basis for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 create action but omits side effects, where the BPMN file is written, whether process_name selects a template or names the output, and what the agent should expect after execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler, which is good for conciseness. However, it is so thin that it omits critical operational and parameter guidance, so the brevity comes at the expense of usefulness.
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?
With no annotations, no output schema, and a bare parameter schema, the description is insufficient for reliable invocation. It does not clarify how a template is selected, what process_name refers to, or what output to expect, and the agent would likely need to consult sibling tools like list_templates or get_template_details first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, process_name, with 0% description coverage, and the tool description does not mention it at all. The phrase 'from a predefined template' does not explain what process_name means, how it maps to a template, or what format is expected, so the agent cannot determine how to populate the parameter.
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 Spanish description uses the verb 'crea' and identifies the resource as 'un proceso BPMN desde una plantilla predefinida', making the core function clear. It is somewhat distinguished from sibling creation tools by the 'predefined template' source, though it does not name specific templates or compare itself to create_from_yaml_spec.
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?
There is no guidance about when to use this tool versus alternatives such as create_simple_linear_process, create_process_with_decision, or create_from_yaml_spec. The only implicit signal is 'template', but no conditions, prerequisites, or exclusion criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one meaningful behavioral trait: all-or-nothing transaction semantics. However, with no annotations provided, the description carries the full burden of disclosing side effects, input requirements, output behavior, or failure handling, and it does not address these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short with no filler, but it is so terse that it sacrifices actionable guidance. Conciseness alone does not compensate for the missing context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations, no output schema, and many closely related siblings, a single phrase about transaction semantics is insufficient. The agent lacks information about input structure, return values, prerequisites, or behavioral outcomes, making reliable invocation unlikely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'description' parameter at all. There is no guidance on format, content, or expected use of the parameter, so the agent receives no semantic help.
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 identifies the tool as creating a process containing a transaction sub-process with all-or-nothing semantics. This distinguishes it from sibling tools like create_simple_linear_process or create_process_with_decision, though it lacks an explicit verb.
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?
There is no guidance on when to choose this tool over the many sibling process-creation tools. The phrase 'todo o nada' hints at transactional use cases, but no explicit when-to-use or alternative-routing information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveals that the tool creates an embedded subprocess with internal activities, but it does not explain side effects, output behavior, required context, validation, or whether an existing process must be selected. This is thin behavioral coverage for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and starts with the action, but it is under-specified. There is no wasted wording, but the brevity comes at the cost of missing necessary context, so it is concise yet not well proportioned for the tool's actual complexity.
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?
With no annotations, no output schema, and only a minimal schema, the description needed to provide substantially more operational context. It covers the core idea but omits how to invoke it, what the parameter should contain, and what happens after creation. The tool is not fully unspecified, but it is far from complete enough for reliable agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single property named 'description' with no type or description, and schema description coverage is 0%. The tool description never explains how to use the 'description' parameter, what kind of content it expects, or how it relates to the 'internal activities' mention. The parameter semantics are effectively undocumented.
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 states a clear action ('Crea') and a specific BPMN resource ('subproceso embebido') with a notable qualifier ('con actividades internas'), which helps distinguish it from sibling tools like create_simple_linear_process or create_call_activity_process. However, it does not explicitly contrast it with the many sibling creation tools, so it is clear but not fully differentiated.
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?
There is no guidance about when to choose this tool over the many sibling creation tools, no prerequisites, and no alternatives mentioned. The description only states what it does, leaving the agent to infer the appropriate usage context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavior. It mentions the resulting process includes a boundary error event and dedicated handler, but it does not describe side effects, output, validation behavior, failure modes, or required permissions.
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 one concise sentence with no filler or redundant information. It is easy to scan, though its brevity comes at the cost of missing important usage and parameter details.
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 absence of annotations, output schema, and meaningful parameter schema, the description is not complete enough for an agent to invoke the tool confidently. It only identifies the process elements and leaves open what to pass, what will happen, and what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'description' has an empty schema with 0% coverage, and the tool description provides no information about what this parameter should contain. Since schema coverage is low, the description needed to compensate, but it does not mention the parameter at all.
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 names a specific resource (a process with a boundary error event and dedicated handler), which distinguishes it from sibling tools like create_process_with_boundary_events. However, it is phrased as a noun phrase ('Proceso con...') rather than an explicit verb, so the agent must infer the 'create' action from the tool name.
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?
There is no guidance on when to use this tool versus the many sibling process-creation tools. The description never mentions alternatives, exclusions, or a preferred context, so the agent is left to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No hay anotaciones que cubran el perfil de comportamiento, y la descripción no informa sobre efectos secundarios, validaciones, generación de archivos, permisos ni formato de retorno. Se limita a repetir la acción de crear, que ya se infiere del nombre.
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?
Es una frase corta, directa y sin relleno. El aspecto clave, boundary events con sus dos variantes, aparece al frente y no hay información redundante.
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?
Para una herramienta de creación sin output schema ni anotaciones, falta especificar el formato esperado del parámetro description, cómo se representan los boundary events y qué resultado o archivo se produce. El agente no puede invocarla correctamente solo con esta definición.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
El schema tiene un único parámetro 'description' con cobertura 0%, y la descripción de la herramienta no explica cómo debe redactarse esa descripción ni cómo expresar boundary events interruptores o no interruptores. El texto no añade ningún significado al parámetro.
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?
La descripción indica con verbo específico 'Crea' y recurso 'proceso con boundary events', añadiendo la distinción interrupting/non-interrupting. Sin embargo, no diferencia explícitamente de herramientas hermanas como create_process_with_timer o add_event_with_trigger.
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 se indica cuándo usar esta herramienta frente a las alternativas del catálogo, ni se mencionan condiciones de exclusión o casos preferentes. El agente no recibe orientación sobre cuándo elegir esta variante en lugar de create_simple_linear_process, create_process_with_parallel, etc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral burden. It only offers a structural label (loops and multi-instance) and does not disclose side effects, input handling, permissions, output behavior, or whether anything is overwritten. This is a significant gap for a creation tool.
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 one short sentence with no wasted words. The qualifiers 'standard' and 'sequential/parallel' add useful detail without bloat. It is appropriately sized for the minimal information it conveys.
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 complex creation tool with no annotations, no output schema, and an undocumented parameter, the description is too thin. It does not cover input format, return value, prerequisites, or how it relates to the BPMN toolset. The sibling list offers context, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'description' has 0% schema coverage and the description says nothing about it. The tool description does not explain what format or content is expected in 'description', so the agent must infer that it is a prose description of a process. The description fails to compensate for the schema gap.
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 names the process type (loops and multi-instance) and distinguishes it from similar tools like create_process_with_parallel or create_simple_linear_process. It lacks an explicit verb, relying on the tool name for the action, but the resource and scope are clear.
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 given on when to choose this tool over alternatives. There is no mention of use cases, exclusions, or conditions that would route an agent here instead of to a sibling like create_process_with_decision or create_subprocess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It communicates that the operation retrieves details, but it does not say what happens for invalid IDs, whether the operation is read-only in practice, what response format to expect, or any side effects. The description is too thin to be transparent.
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 sentence with no filler, front-loading the action and object. It is appropriately concise for a simple retrieval tool, though it is arguably under-specified in other dimensions.
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?
There is no output schema and no annotation coverage, so the description alone must make the tool callable. It does not explain how the 'id' is provided, what details are returned, or how this tool relates to the many template and BPMN siblings. This is inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has zero parameters and the baseline for 0 params is 4, the description introduces an 'id' concept that the input schema does not support. This creates confusion: the agent is told the lookup is by id, but there is no way to supply that id through the schema. The description therefore adds misleading rather than helpful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Obtiene detalles') and resource ('una plantilla BPMN por id'), which distinguishes it from listing templates or creating from templates. It lacks a bit of specificity about what kind of details are returned, but the core 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?
There is no guidance on when to use this tool versus siblings like list_templates, read_bpmn_file, or create_from_template. The phrase 'por id' implies it should be used when an ID is known, but no explicit context, prerequisites, or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the main effect — creating a call-activity process — but says nothing about side effects, validation, whether an existing process must be referenced, or what the tool returns. That is a meaningful gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with the key behavior front-loaded. It is concise and every word earns its place, though the brevity comes at the cost of missing parameter guidance.
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?
This simple tool has one undocumented parameter, no annotations, and no output schema, so the description must compensate. It clarifies the type of process but is silent on input semantics, output, and behavioral expectations. Given the crowded family of create_* siblings, this is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'description' has 0% schema coverage and the description does not mention or explain it. The agent is left without any hint of what value to supply, so the description adds no semantic value over the empty schema.
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 states a specific verb and resource: it creates a process that invokes another process (call activity). This clearly identifies the tool's purpose and broadly distinguishes it from other process-creation siblings, though it does not elaborate on the exact behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The type of process to create implies when to use the tool — when a call activity is needed — but it provides no explicit guidance about alternatives, prerequisites, or when not to use it. This meets the threshold for implied usage but stops short of active routing among the many sibling creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It only says the tool creates a BPMN process with an exclusive gateway; it does not mention what else happens, whether files are written, whether validation occurs, what the output is, or any side effects or prerequisites.
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 clear sentence that is front-loaded with the main action and key distinguishing detail. It is not verbose, but a bit more contextual guidance would make it more useful without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and two undocumented parameters, this description is too thin for an agent to invoke the tool correctly with confidence. It explains the high-level purpose but omits parameter semantics, behavior, and return/output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no meaning for the two parameters, 'description' and 'merge_tasks'. The agent must guess their types and roles; 'merge_tasks' is especially ambiguous without any explanation.
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 states a specific action ('Crea un proceso BPMN') and a specific resource type ('con gateway exclusivo (decisión binaria)'), which distinguishes it from linear and parallel process creators. It is clear and purposeful, though it does not explicitly name a sibling tool as the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the phrase 'gateway exclusivo (decisión binaria)': an agent can infer this tool is for processes requiring an exclusive/binary decision point. However, there is no explicit 'use this when' guidance, no exclusions, and no direct comparison with siblings like create_simple_linear_process or create_process_with_parallel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the creation intent ('Crea un proceso') and reveals nothing about side effects, output location, whether the result is validated, or how merge_tasks affects the generated model. For a generation tool that presumably writes BPMN files, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded with the action verb, containing zero fluff. However, it reads as under-specification rather than appropriate conciseness: for a 2-parameter tool with no annotations and no output schema, more content (parameter hints, output behavior) was needed to be genuinely useful.
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?
At 2 parameters, no output schema, and no annotations, the definition is thin relative to the tool's complexity. Critical context is missing: what the parallel gateway structure looks like, whether a merge gateway is included, and what format the description input should take. An agent would have to guess these details or probe the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions neither parameter. 'description' is self-explanatory from context, but 'merge_tasks' is genuinely ambiguous — it could mean merging parallel branches back into one flow, or merging tasks — and nothing disambiguates it. The description needed to compensate for the schema gap and did not.
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 states a specific verb and resource: 'Crea un proceso BPMN con ramas paralelas (parallel gateway)' — creating a BPMN process with parallel branches. This naturally distinguishes it from obvious siblings like create_simple_linear_process and create_process_with_decision by the parallel-gateway feature. However, it doesn't explicitly name those siblings or the exact distinguishing condition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: choose this tool when the process requires parallel branches. But no exclusions or alternative tools are named, despite a large sibling set (create_simple_linear_process, create_process_with_decision, create_process_with_loops_and_multiinstance) that overlaps on process creation. An agent gets no guidance on when not to use it or how parallel flows differ from decision/loop flows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveals that the tool searches 'best practices' internally, but it does not describe the return format, whether it returns a single explanation or a list, how failures are handled, or what the user will actually see. The read-only nature is implied but not explicitly stated.
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 brief and front-loads the core purpose in a single sentence. It contains no filler. It loses a point because the parenthetical about searching by title or id introduces an important input requirement that the schema does not support.
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 tool with no input schema, no annotations, and no output schema, the description must explain how the agent selects the concept and what the response looks like. It does neither clearly. The reference to title or id hints at selection criteria, but the lack of parameters and absence of output details leave the tool underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions searching 'por título o id', which implies the agent needs to specify a concept by title or id. However, the input schema is empty (properties: {}), so there is no way to pass that information. This is a conflict between the description and the schema that makes invocation ambiguous. The description adds no actionable parameter guidance.
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 states a specific action and resource: 'Explica un concepto BPMN' (explains a BPMN concept). It adds that it searches best practices by title or id, which gives some differentiation from generic catalog or listing tools. However, it does not define what counts as a 'concept' or clarify how it differs from nearby tools like get_best_practices or get_bpmn_cheatsheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: use it when a user wants an explanation of a BPMN concept. There is no explicit guidance about when not to use it or which sibling tool to choose instead, even though many siblings provide reference information about BPMN elements, gateways, events, and best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It merely labels the content as a catalog of swimlanes and does not disclose return format, whether the catalog is static or dynamically generated, or whether any side effects occur. The read-only nature is only inferable from the 'get' prefix, not from the description.
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 very brief and contains no filler; the parenthetical 'pools, lanes' adds a small amount of clarifying domain information. A more explicit verb or sentence structure would improve it, but it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description is minimally adequate in declaring the topic (swimlanes/pools/lanes). However, with no output schema and no statement about what the returned catalog actually contains, an agent cannot fully anticipate the tool's output. The description also does not help an agent choose among the many sibling catalog tools.
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 input schema has zero parameters, so there are no parameter semantics for the description to clarify. Per the zero-parameter baseline, this is acceptable, and the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('Catálogo de swimlanes') and clarifies that swimlanes refer to pools and lanes, so the domain topic is identifiable. However, it lacks a verb and largely restates the tool name; it does not explicitly say the tool returns or retrieves a catalog. It also does not actively distinguish itself from sibling catalog tools beyond the swimlane topic.
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 the many sibling catalog tools, nor are any prerequisites or contexts mentioned. The only usage signal is implicit in the word 'Catálogo' and the tool name. There are no exclusions or alternatives described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the subject matter and does not describe return format, read-only nature, or any other behavior. The 'get' prefix implies retrieval, but the description itself adds no behavioral detail.
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 extremely short and contains no filler, making it easy to scan. It is slightly under-specified as a fragment, but for a parameterless getter this level of brevity is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no annotations, the description conveys the high-level resource but omits the return format and any explanation of what these validation rules look like. With no output schema to fill that gap, a bit more detail would make the tool fully self-explanatory.
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 input schema has zero parameters, so there is no parameter meaning to document. The baseline for a parameterless tool is 4, and the description neither adds nor detracts from that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as BPMN 2.0 validation rules, which is more informative than a pure tautology and separates it from validation actions like validate_bpmn_file and validate_bpmn_xml. However, it is a noun phrase rather than a verb-led statement and does not explicitly say that the tool returns or retrieves these rules.
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?
There is no guidance about when to call this tool versus its many catalog/getter or validation siblings. No context, exclusions, prerequisites, or alternative tools are mentioned, so an agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a topic and does not reveal what the tool actually does or returns, such as a comparison, a list, or explanatory text. There is no mention of limitations, scope, or how the output is structured, which is insufficient for a tool with no other metadata.
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 very short and front-loads the core topic with no filler words. It is appropriately compact for a simple informational tool. However, the noun-phrase style is terse to the point of mild vagueness, so it is concise but not a model of explanatory clarity.
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?
With no output schema and no annotations, the description is the only source of contextual information. It identifies the topic but not the return format, depth of detail, or how this tool differs from overlapping siblings like get_bizagi_extended_info. For an agent selecting among many sibling tools, this is incomplete.
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 an empty schema, so parameter semantics are trivially satisfied. With no parameters to document, the description does not need to add parameter-level detail. The baseline of 4 for parameterless tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('formato Bizagi') and the specific focus (.bpm vs .bpmn), so an agent can infer it explains format differences or specifics. It lacks an explicit verb like 'returns' or 'explains', but the tool name and context make the general purpose reasonably clear. It is distinguishable from generic catalog tools, though it overlaps somewhat with get_bizagi_extended_info.
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?
There is no guidance on when to use this tool versus alternatives such as get_bizagi_extended_info or get_bpmn_cheatsheet. The description implies the tool provides informational content but does not state conditions, exclusions, or selection criteria. An agent would have no basis for choosing among the many similar get_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavior. It only says the tool provides a cheat sheet, with no mention of output format, content coverage, side effects, or whether it reads static content vs. generates something. This is minimal behavioral disclosure.
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 extremely short, which is appropriate for a zero-parameter informational tool. However, it is a noun phrase rather than a complete sentence and adds no useful detail beyond the tool name, so it is not a top-tier concise description.
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?
Despite the simple zero-parameter interface, the description is not complete enough for an agent to know what a 'cheat sheet' will contain or how it relates to the many sibling educational/reference tools. No output schema exists, so the description should have explained the expected content or format.
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 coverage is 100%, so there are no parameter semantics for the description to clarify. Baseline 4 applies because there is nothing missing for an agent to provide as input.
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 identifies a specific resource — a complete BPMN 2.0 cheat sheet — and the tool name adds the 'get' action. It is clear about what artifact is returned, though it does not explicitly differentiate itself from other informational siblings such as explain_bpmn_concept or get_best_practices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this cheat sheet over the many sibling reference tools (get_best_practices, get_validation_rules, catalogs, explain_bpmn_concept). An agent must infer use cases without any stated conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavior. It only reveals a vague sandbox-related constraint and does not describe return values, side effects, error behavior, or what file is actually read. For a tool with zero annotations, this is insufficient behavioral disclosure.
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 short and front-loaded with the core action. No sentences are wasted. However, the parenthetical is awkward and could have been clearer, which slightly reduces the structural quality.
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?
Despite having no parameters, the description does not clarify which file is read or how the agent should identify it. The sandbox note hints at a constraint but does not explain the tool's full behavior or output. An agent cannot fully infer how to invoke or interpret this tool from the description alone.
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 input schema has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics because there are none. It correctly avoids inventing parameters or suggesting inputs that do not exist.
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 states a specific action ('Lee un archivo BPMN/XML') and a resource, making it clear this tool reads BPMN/XML files. The parenthetical sandbox note adds context but is slightly ambiguous about what 'sandbox al directorio de salida' means exactly. It is distinguishable from sibling creation and validation tools, though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like validate_bpmn_file, list_bpmn_elements, or list_generated_files. Usage must be inferred from the tool name and verb. There are no exclusions, prerequisites, or hints about why an agent would choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'validates.' It does not mention whether the tool reads a file from the output directory, whether it is read-only, what the validation result looks like, or whether errors are returned.
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, front-loaded sentence with no wasted words. It is concise, though the brevity comes at the cost of useful context.
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 tool with no annotations, no output schema, and a similarly named sibling, the description is too thin. It leaves unclear which file is validated, how validation is triggered, what the outcome format is, and why validate_bpmn_file should be chosen over validate_bpmn_xml.
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, so there is no parameter meaning for the description to add. The description's mention of 'archivo' provides minimal context about what the tool operates on, which is acceptable for a parameterless tool.
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 ('Valida') and the resource ('un archivo BPMN 2.0'), so an agent can tell this tool is for validating BPMN files. However, it does not explicitly differentiate itself from the sibling validate_bpmn_xml; the only hint is the word 'archivo' as opposed to XML.
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?
There is no guidance about when to use this tool versus validate_bpmn_xml or any other sibling. The description only states what it does, not when it is the preferred choice or what conditions call for an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describing behavior. It never states whether the tool lists, retrieves, or explains definitions, nor does it describe the output form or side-effect profile. It is not misleading, but it is minimally transparent.
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 compact noun phrase with no filler words and the key event categories are front-loaded. It is slightly fragment-like because it lacks an explicit verb, but it remains short and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless info tool, the description is minimally adequate: it communicates the topic and gives relevant examples. However, because there is no output schema and no annotation, the lack of any statement about return content or format leaves a noticeable gap.
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, so there is no parameter burden for the description to carry. The examples of event types add useful semantic context beyond the empty schema.
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 identifies the resource as event definitions and enumerates common event types such as message, timer, signal, and error. It does not include an explicit action verb and does not differentiate this tool from closely related siblings like get_event_matrix.
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?
There is no guidance about when to use this tool instead of alternatives such as get_event_matrix or get_gateway_types_info. The intended use is only implied by the tool name and examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only labels the content as a catalog and does not describe whether the operation is read-only, what response format to expect, or any other behavioral traits beyond the name's implication.
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 short sentence with no filler or repetition. It is appropriately sized for a zero-parameter catalog retrieval, though it could have added slightly more practical detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless catalog tool, the description gives a minimally viable idea of what the tool returns. However, with no output schema and no behavioral or usage details, an agent is left to infer the return format and whether any side effects or prerequisites exist. The low complexity makes this acceptable but not fully complete.
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 input schema has zero parameters, so there are no parameter semantics for the description to clarify. Per the baseline for 0-parameter tools, this is fully adequate; nothing is missing on 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 identifies the resource ('elementos de flujo') and clarifies scope by naming what is included: flows and gateways. This distinguishes it from sibling catalog tools like get_activities_catalog or get_markers_catalog, even though the verb is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus the many sibling catalog tools. The parenthetical '(flows, gateways)' provides an implicit context cue, but the description never states a selection rule or mentions alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears the full burden of explaining behavior. It describes the content but not what the tool returns (e.g., a list, a reference table), whether it is read-only, or any formatting or availability details. The static noun 'catalog' hints at a reference lookup but does not disclose behavioral traits explicitly.
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 very short and front-loaded: it states the resource type first and then gives concrete examples. No wasted words, though it is terse to the point of omitting useful usage and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-free catalog retrieval tool, the description is minimally viable: it names the topic and key subtopics. However, with no output schema, no annotations, and many sibling catalog tools, the description could usefully add what kind of data is returned and when to consult this catalog rather than a sibling one.
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 the schema coverage is 100%, so the description does not need to explain parameter semantics. The baseline of 4 for zero-parameter tools applies; no additional parameter documentation is required.
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 identifies the resource clearly: a catalog of BPMN markers, and even lists the main categories (loops, multi-instance, compensation). This distinguishes it from sibling catalogs like activities or attributes, though it lacks an explicit verb. The tool name 'get' provides the action, making the purpose reasonably clear.
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 given about when to choose this tool over its many catalog siblings (get_activities_catalog, get_attributes_catalog, get_flow_elements_catalog, etc.). The usage context is only implied by the word 'catalog' and the marker examples; neither explicit conditions nor exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states only that the tool 'gets' the directory, but doesn't clarify whether this is a read-only operation, what exactly is returned (e.g., a file path, a list of files, or directory contents), or any side effects. The absence of an output schema amplifies this gap.
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 sentence that conveys the core purpose efficiently. It's front-loaded with the verb and resource, and every word contributes meaning. No fluff or redundancy.
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?
The description is incomplete for an agent needing to invoke the tool correctly. It doesn't specify the return format (path, list, object), whether the directory is static or configurable, or any relationship to generated files. Without an output schema, the agent has insufficient information to interpret results. A more complete description would state the return type and possibly reference sibling tools for file-level operations.
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 the schema is empty (coverage 100%). Per the baseline for 0-param tools, a score of 4 is appropriate because there are no parameters for the description to explain. The description doesn't add parameter-related meaning, but it isn't required to.
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: 'Gets the output directory with generated BPMN files.' The verb 'obtiene' and resource 'directorio de salida' are specific and distinct from sibling tools like list_generated_files or read_bpmn_file, which operate on files rather than the directory itself.
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 usage guidance is provided. The description doesn't explain when to use this tool instead of alternatives, such as list_generated_files or get_bpmn_cheatsheet, nor does it mention any prerequisites or context for querying the output directory. The agent is left to infer its role from the name and sibling catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only lists topic content ('Tipos de task') without stating that the tool returns a reference list, what format the response takes, or any side-effect/safety information. There is no contradiction with annotations, but the behavior is largely implicit.
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 compact and front-loaded with the key term, with examples in parentheses. It is appropriately sized for a parameterless info tool, though it is a fragment rather than a complete sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool this is mostly complete: an agent can invoke it without worrying about inputs. However, there is no output schema and the description does not clarify the return shape beyond the topic, so a fully informed call is not guaranteed. 'etc.' also leaves the content boundaries unspecified.
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, so there is nothing for the description to document. The baseline for zero-parameter tools is 4, and no schema/description concern applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact resource (BPMN task types) and gives concrete examples (userTask, serviceTask, scriptTask), which distinguishes it from sibling tools like get_gateway_types_info and get_event_definitions_info. It lacks an explicit verb, but the tool name's 'get' supplies the action, so the purpose is still clear.
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 given about when to call this tool versus the many sibling options, nor any exclusions or alternatives. The purpose implies it should be used for task-type reference, but the description does not state this explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It says the tool checks availability but does not disclose that it likely returns a boolean, nor does it mention any loading, initialization, or side-effect behavior. It is minimally informative but not misleading.
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 clear sentence with no unnecessary words. The verb and object are front-loaded, making it immediately scannable and appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless capability check, the description is close to sufficient, but the absence of an output schema means the return value is not explicitly described. An agent can infer a boolean result from the name and phrasing, but a short statement of the return type would make it fully complete.
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 the schema already covers 100% of the input contract. With no parameters to document, the description does not need to add parameter-level detail, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Verifica') and resource ('OCR (Tesseract.js) está disponible'), making the tool's purpose clear. It also conceptually distinguishes this from the sibling OCR-based tools like extract_text_from_image, though it does not explicitly name that distinction.
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 given about when to use this tool versus alternatives. The context of sibling tools like create_process_from_image implies it could serve as a precondition check, but that is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, but it only says it creates a BPMN process. It does not disclose whether the generated process is validated, written to a file, overwrites existing artifacts, or what the response contains.
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?
A single front-loaded sentence with no filler; every word contributes to the core purpose and source format. It is appropriately concise for a description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, one undocumented parameter, and many sibling tools, the description is too sparse. It lacks input format details, output expectations, and guidance for distinguishing it from similar creation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single 'description' parameter has no type or explanation. The tool description mentions YAML/JSON specification but never explicitly connects it to the 'description' parameter, so the agent is left to infer how to pass the spec.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Crea un proceso BPMN') and a distinct source format ('especificación YAML/JSON estructurada'), making it distinguishable from siblings such as create_process_from_text_description and create_process_from_image. Despite being in Spanish, the verb + resource + source combination 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The source format implies the tool should be used when the user has a structured YAML/JSON specification, so there is some implied usage context. However, it does not explicitly state when to prefer this over the many sibling creation tools or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the OCR-based extraction mechanism, which is useful, but it is silent on failure modes, OCR availability, how the image is supplied, and whether the generated BPMN process is returned or saved.
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?
A single, front-loaded sentence with no filler; the action, source, and method are conveyed efficiently. It is concise without being tautological.
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 tool with no annotations, no output schema, and only one parameter, the description leaves critical gaps: how the image is specified given the schema only has process_name, whether OCR is built in, and what the tool returns. The basic purpose is clear, but this is not enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, process_name, and the schema provides zero description coverage. The description does not explain what process_name means, whether it is required, or how it relates to the image input, so the agent cannot reliably populate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (creates a BPMN process) plus the source (image) and method (OCR). This makes it clearly distinct from siblings like create_process_from_text_description and extract_text_from_image, so an agent can tell what the tool does at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the input is an image containing process steps, but it never states that explicitly or names alternatives/exclusions. It also does not mention checking is_ocr_available first, even though that sibling exists, leaving usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explaining behavior. It discloses only that the tool creates a BPMN process from a text description; it does not mention what the tool returns, whether a file is written, whether validation occurs, whether prior outputs are overwritten, or how the text description is supplied given the empty input schema.
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, front-loaded Spanish sentence with no filler. The core action, target artifact, and input source are all present in a compact and readable form.
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 empty schema, missing annotations, and lack of output schema, the description is too thin to fully support correct invocation. It does not explain how the textual description is passed to the tool, what kind of BPMN output to expect, or how to distinguish this from the many alternative creation tools in the sibling list.
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 input schema has zero parameters, so the baseline is 4. The description still adds meaning by naming the implicit primary input — a natural-language textual description — which is not represented anywhere in the schema. This helps the agent understand what conversational or contextual material is relevant.
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 names a specific action ('Crea'), a clear resource ('un proceso BPMN'), and the distinctive input mode ('interpretando una descripción textual en lenguaje natural'). It clearly differentiates from image- or YAML-based creation tools, though it does not explicitly position itself against the many pattern-specific process-creation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the agent can infer it should be used when a BPMN process needs to be generated from natural-language text. However, there is no explicit guidance about when not to use it or which sibling alternatives to choose for structured inputs, images, or specialized process patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It only says 'Crea' (creates), which mostly restates the tool name, and discloses nothing about side effects, file writes, required inputs, or return behavior.
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 short sentence with no filler. It conveys the core purpose efficiently and is easy to scan.
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 tool with no annotations, no output schema, and an undocumented parameter, this description leaves important gaps. It does not explain how the 'description' parameter is used, what the tool returns, or what side effects occur.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'description' property with no type or description, and schema description coverage is 0%. The tool description does not explain what the 'description' parameter should contain, its format, or whether it is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: it creates a simple linear BPMN 2.0 process with sequential tasks. This clearly distinguishes it from sibling tools like create_process_with_decision and create_process_with_parallel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'lineal simple con tareas secuenciales' implies this tool is for simple sequential workflows, but the description never explicitly says when to use it or when to prefer a sibling like create_process_with_decision. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. The core behavior is disclosed ('using OCR', 'extract text'), but details such as how the image is provided, what the output looks like, and failure behavior are absent.
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, front-loaded sentence with no wasted words. It is concise and immediately communicates the 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?
Despite the low complexity, there are no annotations and no output schema to compensate. The description does not explain where the image comes from, what the extracted text is used for, or whether OCR availability is required, leaving important invocation context to inference.
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 input schema is empty and has no parameters, so the description needs to explain no parameters. The high schema coverage (100%) and zero-parameter baseline make this a 4.
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 states a clear verb and resource: 'Extraexto de una imagen usando OCR'. It is unambiguously about extracting text from an image, but it does not explicitly differentiate itself from siblings like create_process_from_image, which could also involve images.
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?
There is no guidance about when to use this tool instead of alternatives. It does not mention prerequisites such as is_ocr_available, nor does it explain the intended workflow relationship with create_process_from_image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 names the topic (gateway types) and does not explicitly state that the tool is read-only, what it returns, or whether it fetches a list, definitions, or examples. The parenthetical list hints at content but does not describe the tool's behavior.
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 enumerative phrase with no filler or redundant wording. Every element adds semantic value by specifying exactly which gateway types are covered, making it appropriately sized for a simple no-parameter informational tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter reference tool, the description adequately conveys what content the agent will get (gateway type categories). The main gap is that it does not explicitly describe the return format or whether the tool provides descriptions versus just names, but this is minor given the simplicity and the tool name.
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 input schema has zero properties, so there are no parameter semantics that need clarification. The description adds useful content context by listing the gateway type categories, which satisfies the baseline expectation for a parameter-free tool.
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 identifies the resource as gateway types and enumerates them (exclusive, parallel, inclusive, event-based, complex), which distinguishes it from sibling tools like get_event_definitions_info and get_task_types_info. It lacks an explicit action verb like 'returns' or 'lists', but the combination of tool name and content makes the purpose 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?
The description gives no guidance on when to use this tool versus alternatives such as get_flow_elements_catalog or get_best_practices. There are no exclusions, prerequisites, or routing hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It states that the tool performs validation, which implies a read-only, non-destructive behavior, but it does not describe return values, error reporting, or any side effects. With no annotations provided, the description carries the full burden, so a bit more behavioral detail would be expected.
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?
A single sentence with no filler or redundancy. It is appropriately sized for a tool with no input parameters and is front-loaded with the action and target.
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?
The description references validating an XML string, but the schema defines no input parameters, so an agent cannot tell how to pass the string. There is also no output schema or explanation of validation results. Given zero annotations and no schema support, the description is not sufficient to invoke the tool confidently.
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 input schema has zero properties, so the description cannot add per-parameter detail; the baseline for zero parameters is 4. The description does add meaningful context by identifying the input as an XML string for BPMN 2.0, though it does not name how that string is supplied.
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 uses a clear verb ('Valida') and a specific resource ('string XML BPMN 2.0'), so the core purpose is immediately understandable. It does not explicitly contrast with the sibling validate_bpmn_file, though 'string' hints at the difference.
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?
There is no guidance on when to use this tool versus validate_bpmn_file or the many process-creation tools. The intended usage is only implied by the tool name and brief description, with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that a process is created, but does not explain side effects, whether files are written, whether validation occurs, what the output is, or what happens on failure. This is minimal for a mutation-like tool.
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, focused sentence with no filler or repetition. It front-loads the core purpose and includes a helpful clarification of the timer event type in parentheses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool, the description is minimally adequate: it tells the agent what kind of process will be created. However, with no output schema and no annotations, the agent is left without information about what the tool returns, whether a file is generated, or what post-conditions hold. This is a clear but not severe gap.
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, so the schema is trivially complete. Per the rubric, 0 parameters receives a baseline of 4. No additional parameter explanation is needed because there are no inputs to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Crea un proceso') and a specific resource ('con timer event intermedio (wait/schedule)'). This distinguishes it from sibling tools like create_process_with_decision or create_process_with_parallel, making the tool's purpose immediately clear.
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?
There is no guidance about when to use this tool instead of the many sibling creation tools. It does not mention use cases, exclusions, or alternatives such as create_process_from_text_description or create_from_yaml_spec. The usage context is only implicit from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It adds content scope (data objects and annotations) beyond the bare tool name, and 'catalog' implies a read-only retrieval operation. However, it does not explicitly state that the tool returns a list, that it has no side effects, or what the response looks like, leaving some inference to the agent.
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 extremely compact, front-loaded with the key resource name, and contains only one meaningful parenthetical. There is no filler or redundancy, which is appropriate for a zero-parameter getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema catalog getter, the description is mostly complete: it names the catalog and clarifies its contents, which is the main thing an agent needs to invoke it correctly. It is slightly thin on explicit retrieval behavior and differentiation from sibling catalogs, but those are minor gaps given the tool's simplicity.
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 an empty input schema, so there is no parameter semantics burden. Per the guidelines, zero parameters receives a baseline of 4. The description and schema are consistent.
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 identifies the resource ('Catálogo de artefactos') and disambiguates it with the parenthetical '(data objects, annotations)', separating it from sibling catalog tools such as activities, markers, attributes, flow elements, and swimlanes. However, it is a noun phrase rather than an explicit verbed statement like 'returns the artifact catalog', so it stops short of fully stating the action.
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?
There is no usage guidance. The description does not mention when to choose this catalog over get_activities_catalog, get_flow_elements_catalog, get_swimlanes_catalog, or other sibling catalogs, nor does it state any exclusions or complementary relationships.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'Lista' implies a read-only operation with no side effects, which is useful, but the description does not mention return format, whether the list is static, or any limitations. This is minimally adequate but not rich.
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 sentence with no filler or redundant information. Every word contributes meaning, and the core action and object are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with no output schema, the description adequately communicates the return concept: all supported BPMN 2.0 elements. It could be stronger by naming the output shape or clarifying overlaps with sibling catalogs, but overall it is sufficiently complete for such a simple operation.
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 the schema coverage is 100%, so there are no parameter semantics to document. The description adds value by clarifying the scope ('BPMN 2.0 soportados'), which is enough for a no-argument tool.
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 states a clear verb 'Lista' and a specific resource: 'todos los elementos BPMN 2.0 soportados.' It is easy to understand what the tool does. However, it does not distinguish itself from sibling catalog tools like get_flow_elements_catalog or get_activities_catalog, so the differentiation is left to the agent.
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 the many sibling catalog and reference tools. An agent must infer that this is the general-purpose listing tool, which is not explicitly stated. There are no alternatives, exclusions, or contextual triggers mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden for behavioral disclosure. 'Catálogo' plus the getter name imply a read-only listing with no side effects, but the description adds no explicit statements about return shape, ordering, or other behavioral details. For a zero-parameter catalog tool this is acceptable though minimal.
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 short sentence with no filler. It succeeds in being extremely concise while still naming the resource and its scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter catalog getter with no output schema, the description provides the essential information: what the catalog contains. It could mention more about output organization or typical use, but nothing critical is missing for selecting and invoking this tool.
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 no parameters, and schema coverage is effectively complete with an empty object. Per the baseline for zero-parameter tools, the description need not compensate for parameter documentation; the parenthetical 'tareas y subprocesos' adds useful content semantics about what the returned catalog covers.
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 names the resource (activities catalog) and scopes it with 'tareas y subprocesos', which helps distinguish it from sibling catalogs like markers, attributes, and artifacts. It is a noun phrase rather than a full sentence with an explicit verb, but the tool name 'get' makes the action clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: an agent would call this when it needs a catalog of activities/tasks/subprocesses. However, the description does not explicitly say when to prefer this over the many sibling catalog tools, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It communicates that the tool returns a complete event matrix, implying a read-only reference lookup, but it does not describe the return format, whether the data is static, or any other behavioral details. This is adequate but minimal.
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 concise sentence that front-loads the tool's purpose and structure. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter reference tool with no output schema, the description is reasonably complete: it tells the agent what the matrix contains and how it is organized. It could go further by describing the exact return representation, but the core selection and invocation context is clear.
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 the schema is fully described with an empty properties object. There is nothing extra the description needs to add about parameters, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific resource: a complete BPMN 2.0 event matrix, and states the exact dimensions (start/intermediate/end x all triggers). This distinguishes it from sibling catalog tools like get_event_definitions_info or get_flow_elements_catalog because it explicitly presents the matrix structure.
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 gives no guidance on when to use this tool versus siblings such as get_event_definitions_info or get_bpmn_cheatsheet. There is no mention of alternatives, prerequisites, or situations where a different catalog would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No hay anotaciones, así que la descripción deben transmitir su comportamiento. 'Lista' insinúa una operación de solo lectura y 'directorio de salida' delimita el alcance espacial, pero no se explica si devuelve rutas absolutas, nombres de archivo, si es recursivo o qué ocurre si no hay archivos generados.
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?
Es una sola oración clara y directa que comienza con el verbo principar y el objeto. No hay redondancia ni información superflua; cada palabra aporta.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para una herramiento sin parámetros y de complejidad bája, la descripción es casi suficiente: define qué lista y dónde. Sin embargo, al no existir esquema de salida ni anotaciones, sería útil espcificar el formato de la lista devuelta (rutas, nombres, etc.).
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?
El esquema de entrada esta vacío y no hay parámetros que documentar, por lo que la descripción no necesita aportar semántica adicional sobre parámetros. La base para ausencia de parámetros es 4 y el texto no introduce ambigüedad sobre argumentos.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
La descripción usa un verbo específico ('Lista') y un recurso claro ('archivos BPMN generados en el directorio de salida'). Se distingue de siblings como list_templates o read_bpmn_file: no lista plantillas ni lee contenidos, solo enumera archivos generados.
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 se indica cuándo preferir esta herramienta frente a alternativas como get_output_directory, list_templates o read_bpmn_file. Tampoco se mencionan exclusiones o condiciones de uso; el contexto de uso queda solo implícito por el nombre y la descripción.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly signals a read-only listing operation and scopes the resource to predefined BPMN templates, but it does not disclose output format, ordering, or any other behavioral details. This is acceptable for a simple list operation but not richly transparent.
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, focused sentence that front-loads the key information. It contains no filler and earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool, the description is sufficient to understand the primary purpose. It does not describe the return shape, but given the absence of an output schema and the simplicity of a list operation, the gap is minor.
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 the schema is empty, so the baseline of 4 applies. There are no parameter semantics to describe, and the description adds nothing unnecessary about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista') and a clear resource ('todas las plantillas BPMN predefinidas'), making the tool's function immediately obvious. It also differentiates from siblings like get_template_details and create_from_template by focusing on enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage scenario: when an agent needs to know what predefined BPMN templates exist. It does not explicitly state when to prefer this over related tools such as get_template_details or create_from_template, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bpmn-generator-mcp MCP server](https://glama.ai/mcp/servers/johnleyva28/bpmn-generator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/johnleyva28/bpmn-generator-mcp)

Score Badge

Copy to your README.md:

[![bpmn-generator-mcp MCP server](https://glama.ai/mcp/servers/johnleyva28/bpmn-generator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/johnleyva28/bpmn-generator-mcp)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/johnleyva28/bpmn-generator-mcp'

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