Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the path restriction, a meaningful behavioral constraint. But it does not mention potential side effects like replacing the current scene or whether the simulation must be stopped before loading, which could be important for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two concise sentences with no wasted words. The first states the action and object, the second adds a crucial constraint, making it easy to parse quickly.

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

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

For a simple one-parameter tool, the description covers the essential purpose and constraint. The output schema presumably documents return values, so that is not a gap. It could be more complete by noting whether loading replaces the current scene or requires a stopped simulation, but these are minor omissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has only a bare 'ruta' string parameter with 0% description coverage, so the description must compensate. It does by specifying that the path must point to a .ttt or .xml file and must be located beneath the configured COPPELIA_DIRECTORIO_ESCENAS directory, giving the parameter clear semantic meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb 'Carga' (loads) and clearly identifies the resource: a scene file with .ttt or .xml extension from disk. This distinguishes it from sibling tools like cerrar_escena (close scene) and simulation control tools, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The usage is implied by the verb and resource: use this to load a scene file. The description adds a clear constraint that only paths under COPPELIA_DIRECTORIO_ESCENAS are allowed, which guides when and how to call it. However, it does not explicitly mention alternatives or when not to use it.

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

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 reveals a critical non-obvious security risk: external .ttm files can contain Lua child scripts that execute on Play, so loading an arbitrary path is equivalent to running untrusted code. This is exactly the kind of behavior an agent needs to know before invoking the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is front-loaded with the core action, then explains the key parameter, then gives a concise security rationale. Every sentence earns its place, and the structure guides the reader from purpose to constraints to risk.

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

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

The security context, path restriction, and link to listar_modelos make the tool safe and usable. The main gap is that x, y, and z are not described at all, even though they likely control placement; an agent might still infer their meaning from names and defaults, but explicit documentation would make the tool fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It richly explains the required 'modelo' parameter, including its origin, format, and an example, but it says nothing about the x, y, and z parameters, which remain only minimally indicated by their names and default values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description states a specific verb ('Carga') and resource ('un modelo .ttm de la librería de CoppeliaSim en la escena'), clearly distinguishing it from loading a whole scene (cargar_escena). It even provides an example path to remove ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It explicitly directs the agent to obtain the model path from listar_modelos, and explains why only library paths are allowed. It does not directly contrast with cargar_escena, but the scope is clear enough for an agent to decide when this tool is appropriate.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, and the description does not disclose side effects (e.g., whether closing the scene affects simulation state, objects, or unsaved data). This leaves behavioral impact ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, succinct sentence with no unnecessary words or repetition, achieving maximum conciseness.

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

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

Given the simplicity (no parameters, no annotations), the description is adequately complete for the tool's purpose. However, it lacks nuance about when this action is appropriate, so it is not a perfect 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters (0 params), so the schema coverage is complete. The baseline for 0 params is 4; the description does not need to add parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description 'Cierra la escena actual' clearly states the action (close) and the resource (current scene), making it distinct from sibling commands like 'iniciar_simulacion' or 'cargar_escena'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description does not provide context on when to close the scene (e.g., after completing tasks) or contrast with alternative commands. It is implied but not explicit.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full transparency burden. It discloses the key behavioral trait that this tool performs an immediate physical detection rather than reading cached simulation state. It does not mention possible errors, permissions, or side effects, but for a simple probe tool these are less critical and are partly covered by the presence of an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is three short sentences, front-loaded with the core action, followed by a useful contrast and an intended-use statement. Every sentence adds information and no redundant filler is present.

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

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

For a one-parameter tool with an output schema, the description is largely complete: it communicates purpose, timing, simulation independence, and differentiates the sibling tool. The main gap is the lack of parameter semantics, and the absence of annotations leaves the safety/permission profile unstated; nevertheless, the overall context is sufficient for selection in most cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0% and the description does not explain the 'sensor' parameter beyond its name. The parameter name suggests it identifies a proximity sensor, but no guidance about valid values, object naming, or how missing/invalid sensors behave is given, so the description does not compensate for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description opens with a specific verb and resource: 'Detecta ahora mismo con un sensor de proximidad, sin necesidad de simulación.' It clearly identifies the real-time detection action and explicitly distinguishes this tool from 'leer_sensor_proximidad', making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It names the sibling alternative 'leer_sensor_proximidad' and explains why it is not the right choice for live detection: that tool only returns the last simulator sweep and reports nothing when simulation is stopped. It then states for this tool 'sirve para verificar una escena en reposo', giving a clear when-to-use context.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the behavioral burden. It discloses non-obvious facts: the joint moves along its own +Z, the tool applies the axis rotation automatically, the motor stays inert until dynamic control mode is set, and insufficient par_maximo causes silent slow behavior with no error.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured: purpose, parameter legend, two hard-to-discover notes, and follow-up steps. Every section adds non-obvious value, and the most important behavioral caveats are explicitly highlighted rather than buried.

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

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

For a 9-parameter creation tool with no annotations and a 0% schema description coverage, the description covers the essential creation semantics, hidden behavior, and required follow-up actions. The output schema handles return values. The main gap is the undocumented x/y/z and alias parameters, which prevents full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description is the only documentation for parameters. It thoroughly explains tipo, eje, modo, par_maximo, and padre with concrete examples and units. However, it omits x, y, z, and alias entirely, leaving those parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description opens with a specific verb and resource: 'Crea una articulación motorizada y la deja lista para recibir órdenes.' It clearly distinguishes this from rigid-union and simulation tools, and the detailed type/mode explanations reinforce what the tool produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear usage context: it explains when to use each mode, warns about axis orientation, and explicitly lists the post-creation workflow with emparentar_objeto, fijar_dinamica, and fijar_velocidad_junta. However, it does not state when to prefer an alternative like crear_union_rigida or explicitly list exclusions.

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

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 does a good job by revealing that the tool returns a path, that unnamed objects receive default CoppeliaSim names, and that parenting can rename siblings and invalidate previously returned paths. This is a critical side-effect warning. It does not discuss error cases or whether simulation must be running, but the core behavioral risk is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loaded. The primary purpose appears in the first sentence, followed by a concise parameter legend and a necessary warning about alias behavior. Every sentence adds value; there is no fluff or repetition.

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

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

Given that there is an output schema and 8 parameters with no annotations, the description covers the essential operational context: what is created, what values are accepted, units of measurement, and a subtle path-stability caveat. It does not cover duplicate-alias behavior or whether the scene must be in a particular state, but these are secondary gaps rather than fundamental omissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It does so by listing valid values for 'forma', stating that sizes and position are in meters, and explaining the 'alias' parameter's role and its impact on path stability. This adds meaning beyond the bare schema names, though it does not explicitly map each coordinate or size parameter to its intended semantic beyond 'position' and 'sizes'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb and resource: 'Crea una forma primitiva en la escena y devuelve su ruta.' It clearly identifies the action, the object being created, and the return value. It also enumerates the supported primitive types, making the tool's scope unambiguous and distinguishing it from sibling creation tools like crear_junta or cargar_modelo.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage context is implied: use this tool when you need to create a primitive shape such as a cube, sphere, or cylinder. However, it does not explicitly state when not to use it or mention alternatives like cargar_modelo for importing models or crear_junta for joints. The guidance is enough to infer intent but not explicit about trade-offs.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains the sensor's orientation and warns about ground interference, offering transparency about spatial behavior. However, it does not disclose expected return values, side effects (e.g., scene modifications), or potential errors, leaving some behavioral aspects unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is concise overall, but the 'two geometry pitfalls' section adds length. It is structured logically and every sentence provides value, though the pitfall explanation could be trimmed without losing essential information.

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

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

The description covers creation, orientation, and one practical trap, but lacks details on return values, error handling, and the alias parameter. Given the tool's moderate complexity, these omissions leave gaps for a complete understanding of its usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains x, y, z as position in meters relative to parent, alcance as range, apertura_grados as cone angle, and padre as parent path. However, it omits the 'alias' parameter entirely, which is present in the schema, leaving its purpose undocumented and reducing semantic completeness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool creates a conical proximity sensor and orients it forward (+X). It distinguishes itself from sibling tools like 'leer_sensor_proximidad' (read sensor) and 'comprobar_sensor_proximidad' (check sensor), which are for reading or verifying existence, making the creation purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides practical guidance on common geometry pitfalls (sensor orientation and ground detection) that affect usage, but it does not explicitly state when to prefer this tool over alternatives. The intended use case (creating a sensor) is implicit given the tool's name and sibling context.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It explains that this tool creates a force sensor, not an actual weld, and that it also measures the force through the union. It clearly states that simply parenting dynamic shapes does not unite them and that this sensor is the actual joining mechanism.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is longer than minimal, but every paragraph contributes meaningful conceptual or usage information. It is front-loaded with the main purpose and then builds to a concrete use case. The friction example is illustrative rather than filler.

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

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

The description gives strong high-level guidance and even points to the related tool for reading force, and an output schema exists. However, the five parameters are undocumented in both schema and description, leaving a significant gap for an agent that must construct valid arguments.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not explain x, y, z, alias, or padre. The parent-child relationship is hinted at by 'se crea colgando del chasis,' but parameter names, units, coordinate frame, and default behavior are left entirely to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description opens with 'Crea un sensor de fuerza', a specific verb and resource, and immediately clarifies that this is how two dynamic bodies are rigidly joined. It distinguishes itself from alternatives like crear_junta and fusing shapes by explaining exactly when the force-sensor approach is required.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly explains when to use this tool versus parent-child dynamic linking or fusing shapes, including the friction-coefficient edge case where the force sensor is the only option. It also provides a clear usage pattern: create attached to the chassis, then parent the target piece with emparentar_objeto.

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

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 simply says 'stops the simulation' without detailing side effects (e.g., does it reset the scene, clear object states, or just halt execution?). No mention of prerequisites, reversibility, or impact on related tools. This is minimal disclosure for a state-changing operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, clear sentence. It is concise and front-loaded with the action verb. No extraneous wording.

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

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

The tool is simple (no params, no side effects stated), and there is an output schema (though not shown). However, given the lack of annotations, the description could benefit from mentioning any relevant behavioral details such as whether the simulation state resets or if it returns a status. Since it's a straightforward stop command, this is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters and 100% schema description coverage (since it's empty). Baseline for 0 params is 4. The description adds no parameter info, but none is needed. It correctly reflects a parameterless operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the action: 'Detiene la simulación en CoppeliaSim' (stops the simulation in CoppeliaSim). It uses a specific verb ('Detiene') and resource ('la simulación'), distinguishing it from sibling tools like 'pausar_simulacion' (pause) and 'iniciar_simulacion' (start). No ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is provided about when to use this tool versus alternatives like pausar_simulacion or estado_simulacion. The description only states what it does, not whether it should be used for stopping vs pausing, or any prerequisites. Without explicit usage context, the agent may mis-select.

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

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 only restates the action already implied by the tool name, without mentioning that deletion is irreversible, what happens to child objects, permission requirements, or error behavior. This is insufficient for a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single concise sentence, front-loaded with the action, and contains no redundant wording. Every word contributes meaning, making it highly efficient.

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

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

Despite being a simple tool, it is destructive and lacks annotations. The description omits important context such as effects on the scene hierarchy, error handling, and required preconditions. An output schema exists but is not shown; still, the description alone is insufficient for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. The phrase 'por su ruta' adds meaning by suggesting the 'nombre' parameter is a path, but it doesn't clarify the path format or behavior on invalid input. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the action (elimina/deletes) and the resource (objeto de la escena/object from the scene). It distinguishes from siblings like crear_primitiva. However, there is a slight ambiguity: it says 'por su ruta' (by its path) while the schema parameter is 'nombre' (name), which could confuse the identifier type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is provided about when to use this tool versus alternatives, nor about prerequisites such as the object being loaded or the need to use listar_objetos first. The description only states what the tool does, not when to invoke it.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden of disclosing behavior. It explicitly warns that parenting renumbers sibling paths ('emparentar renumera las rutas de los hermanos'), a significant side effect. However, it does not mention potential permissions, error conditions, or what happens to the object's pose beyond the parameter explanation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is concise and front-loaded with the main purpose. It uses two short paragraphs, clearly separates parameter explanations from the warning. The warning is slightly verbose but necessary. Overall efficient.

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

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

The tool has an output schema (not provided) and is a mutation with side effects. The description covers the essential behavior, parameter meanings, and a critical caution about path renumbering. It is sufficiently complete for an agent to use correctly, though it could include more about return values or failure modes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has no descriptions (0% coverage), so the description must compensate. It explains 'padre' and 'mantener_pose' in detail, but does not explicitly define 'objeto', which is required. While it can be inferred from context, the lack of explicit clarification for the core parameter is a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's purpose: 'Cuelga un objeto de otro, para que se muevan como un solo cuerpo' (hangs an object from another so they move as one). It uses a specific verb and resource, distinguishing it from sibling tools like fijar_orientacion or obtener_posicion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides a practical usage warning: 'Si vas a emparentar varias piezas seguidas, vuelve a listar los objetos entre una llamada y la siguiente' (re-list objects between consecutive parenting calls). This guides the user on how to handle a common scenario, though it does not explicitly mention alternative tools or when not to use it.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully carry the behavioral transparency burden. It states only that it queries simulation state, but does not disclose whether this is a safe, non-mutating operation, what the output format is, or potential side effects. The available output schema might add some structure, but the description itself is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, clear sentence: 'Consulta si la simulación está detenida, corriendo o pausada.' It contains no filler and immediately states the tool's purpose. For a simple tool with no parameters, this is appropriately concise and well-structured.

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

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

Given the tool's simplicity (no parameters, output schema present), the description is minimally adequate. However, it could benefit from mentioning the three possible states explicitly in a structured way, and possibly referencing the output schema to clarify return values. It does not address potential error conditions or when the simulation might be unavailable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100%, so there are no parameters to explain. The description correctly focuses on the tool's function rather than parameters, warranting a baseline score of 4 as specified in the rubric for 0-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's purpose: to query the simulation status (stopped, running, or paused). While it doesn't explicitly differentiate from siblings like iniciar/detener/pausar, the verb 'consulta' and the resource 'simulación' make the function clear enough. Lacks mention of alternatives, but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 other simulation control tools. It doesn't mention that this is a read-only alternative to tools like iniciar_simulacion or detener_simulacion, nor does it suggest appropriate context. Usage is implied but not explicit.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral burden. It adds useful non-obvious context: RGB components are normalized to 0–1 and the color affects captures/identification. However, it does not disclose whether the change is persistent, whether the named shape must already exist, or whether it overrides previous colors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences with the main action front-loaded and no filler. The second sentence adds a useful example but is slightly more elaborate than strictly necessary, so it is concise but not maximally lean.

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

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

For a simple set-color operation, the description is close to sufficient: action, parameter range, and purpose are present. Missing are explicit target resolution (what 'nombre' refers to), preconditions such as the object existing, and side-effect/return behavior; the output schema reduces the need for return documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The phrase 'Componentes de 0 a 1' adds a critical constraint to r/g/b that the schema does not provide (schema description coverage is 0%). It leaves the 'nombre' parameter unexplained and does not explicitly map components to r/g/b, though the schema titles partially cover that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a concrete action ('Pinta una forma') and the resource ('forma'), and the tool name 'fijar_color' plus the sibling set of fijar_* tools make it distinguishable as the color-setter among position/orientation setters. It does not explicitly say 'sets the color of the object/shape named by nombre', so the resource is slightly vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides a clear usage context: color is functional for distinguishing objects in a capture, not merely aesthetic. This implies when to use the tool, but it does not explicitly state when not to use it or point to an alternative tool.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool changes an object's detectability, explains the consequence (invisibility to 'leer_sensor_proximidad'), and offers a troubleshooting tip. This adds behavioral context beyond the schema, though it does not mention reversibility or permissions, but the toggle nature is implied by 'marca o desmarca'. No contradiction with annotations (none present).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two sentences, front-loaded with the core action, and every sentence adds value. The second sentence provides meaningful operational insight (cause of sensor malfunction) without fluff. Highly concise and well-structured.

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

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

The tool is simple with only 2 parameters, and an output schema exists, so the description needn't explain return values. It covers the purpose, the effect on sensors, and a practical use case. However, it lacks parameter explanations, which are partially covered in the parameter semantics score. Overall, given the simple nature of the tool and existing schema, the description is fairly complete, but not perfect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It explains the concept of 'detectable' implicitly but never explicitly describes the 'nombre' parameter or how to use the 'detectable' boolean (e.g., what values map to marking/unmarking). It does not add any parameter-level detail beyond what the schema's titles already imply. This is a significant gap given the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

Purpose is explicitly stated: 'Marca o desmarca un objeto como detectable por los sensores de proximidad.' The verb 'marca/desmarca' and resource 'objeto' are specific, and it distinguishes itself from siblings like 'fijar_orientacion' or 'obtener_posicion' by focusing on detectability for proximity sensors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context on when this tool is relevant: it explains how non-detectable objects affect 'leer_sensor_proximidad' and that it is a common cause of sensor malfunction. This implies when to use it (when sensors appear broken), but it does not explicitly contrast with alternatives like 'crear_sensor_proximidad' or give a formal when-not-to-use. This is clear context without explicit exclusions.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does so well: it explains that non-respondable dynamic bodies fall through the floor, that dinamico=False anchors the shape, that negative friction means 'do not touch', and that density mass calculation only works on convex shapes. It does not cover side effects like reversibility or errors, but the provided failure modes and sentinel-value semantics are substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is front-loaded with the core purpose and then uses line-separated parameter definitions without filler. Each sentence adds useful information, especially the warnings about non-respondable bodies and density constraints.

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

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

For a 6-parameter mutation tool with no annotations, the description covers the main behaviors, parameter semantics, edge cases, and the workflow context after crear_primitiva. Since an output schema exists, the lack of return-value explanation is acceptable; nothing critical is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates by explaining five of six parameters with units (kg/m³), sentinel meanings (0 = don't touch mass, negative = don't touch friction), and physical consequences. Only 'nombre' is left to its self-evident title, which is a minor gap for low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a specific action—'Deja una forma lista para el motor de física'—with a clear resource ('forma') and scope (mass, contact, friction). It positions the tool relative to the sibling flow by calling it 'el paso que falta entre crear_primitiva y tener un robot,' which distinguishes it from creation/placement siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly tells the agent when to call it: after creating a primitive, before the object behaves physically; without it a shape is 'decorado' and neither falls nor pushes. It gives clear context but does not name exclusions or alternative tools such as fijar_posicion, so it stops short of a full when-not guide.

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

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 adds the nuance that the position is a 'target' (objetivo) rather than a direct instantaneous set, and mentions units, but it does not disclose whether the command triggers motion, requires a running simulation, or has any side effects. This is insufficient transparency for a mutation tool in a robotics context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, well-structured sentence that immediately states the purpose and includes a useful parenthetical about units. There is no redundant phrasing or filler, and every word contributes to understanding the tool's core function.

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

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

Given the rich set of sibling tools (fijar_posicion, fijar_velocidad_junta, etc.) and the presence of an output schema, the description is too sparse to be contextually complete. It lacks guidance on how to select this tool, what the 'junta' parameter refers to, and the behavior when commands are issued. While the output schema reduces the need to describe return values, the description still misses critical selection and usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clarifies that 'posicion' is measured in radians or meters, but provides no explanation of the 'junta' parameter (e.g., name, ID, or index) and does not specify which joint types use which units. This is minimal added meaning beyond the raw schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's action: 'Fija la posición objetivo de una articulación' (sets the target position of a joint). It uses a specific verb and resource, and the phrase 'articulación' differentiates it from sibling tools like 'fijar_posicion' which likely sets object positions. The parenthetical '(radianes o metros)' further clarifies the semantic scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage by naming the exact operation (setting a joint's target position) but offers no explicit guidance on when to choose this tool over alternatives like 'fijar_posicion' or 'fijar_velocidad_junta'. There are no exclusions or alternative references, leaving the agent to infer the appropriate context from the tool name and resource.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that it sets orientation with Euler angles but not its effect on the simulation state, possible errors (e.g., object not found), or return values. Since no annotations are provided, the description carries the full burden, yet it remains minimal and does not cover side effects or preconditions beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single concise sentence, front-loaded with the key purpose. No redundant words or filler; it stays to the point and is easy to parse.

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

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

For a tool with 5 parameters and no schema coverage, the description is insufficient. It misses usage context, parameter details for 'relativo_a', and does not explain what happens on success or failure. Even though an output schema exists, the description alone is too thin for an agent to understand the full scope of the tool, especially with no annotations to assist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains that alfa, beta, and gamma are Euler angles in radians, adding value beyond the schema that only lists them as numbers. However, it fails to explain the 'nombre' parameter (object identifier) and completely omits 'relativo_a' (reference frame), despite the schema having a default and possible implications. With 0% schema coverage, the description should explain all parameters, but it covers only part of them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool sets an object's orientation using Euler angles in radians. It uses a specific verb (fija) and resource (orientación de un objeto), distinguishing it from siblings like obtener_orientacion (get) and fijar_posicion (set position).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is provided on when to use this tool vs alternatives (e.g., obtener_orientacion for reading, fijar_posicion for position). No context or exclusions are mentioned, leaving the agent to infer usage from the function name alone.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states the action without revealing side effects, error conditions, or whether the position is absolute or relative. The existence of the parameter 'relativo_a' suggests a reference frame, but this is not explained. There is no mention of what happens if the object is already at that position or if coordinates are out of range.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, clear sentence with no unnecessary words. It communicates the core function efficiently, making it easy for an agent to parse and act upon.

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

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

Given the tool's simplicity, the description covers the main action and units, but it omits critical context about the 'relativo_a' parameter and the coordinate frame. While the output schema is indicated to exist, the description does not mention expected return values or side effects, leaving some gaps for an agent to trust the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description only explains the meaning of x, y, z as coordinates in meters, but it does not clarify the role of 'nombre' (object name) or 'relativo_a' (relative to). Since the schema provides no descriptions, the description fails to add value for these parameters, leaving significant ambiguity about the reference frame and object identification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's function: moving an object to a specified position (x, y, z). It is specific with a verb (mover) and resource (objeto), and it distinguishes itself from sibling tools like fijar_orientacion (set orientation). The inclusion of units (metros) adds precision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention scenarios where setting position is appropriate, nor does it contrast with sibling functions like obtener_posicion or fijar_orientacion. Users are left to infer usage from context.

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

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 action ('Fija la velocidad objetivo') without mentioning side effects, whether it is a write operation, required permissions, units, or interaction with the simulation lifecycle.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, front-loaded sentence with no wasted words. It conveys the core purpose efficiently and is appropriately concise for a simple two-parameter setter tool.

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

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

The tool is simple, and the description covers the basic action and object, but it lacks important context such as units for velocity, whether the joint must exist, or when the tool should be used relative to simulation state. The presence of an output schema reduces the need to describe return values, but the description is only minimally sufficient for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero description coverage; the parameter descriptions are just titles 'Junta' and 'Velocidad'. The tool description adds only that the velocity is an 'objetivo' (target), but does not explain the format of 'junta', units of 'velocidad', valid ranges, or any other semantic detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb 'Fija' and a specific resource 'la velocidad objetivo de una articulación', clearly indicating the tool sets a joint's target velocity. It is clear but does not explicitly distinguish itself from sibling tools such as 'fijar_objetivo_junta', so it does not fully earn a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about simulation state or prerequisites. The only implied usage comes from the tool name and general purpose, which is not enough guidance.

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

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 the directory constraint, the overwrite refusal, and the irreversible nature of overwriting another scene, which is critical for a mutation tool. This goes well beyond a generic save statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences, front-loaded with the core purpose followed by necessary safety details. It contains no filler and does not redundantly repeat schema defaults beyond what adds value.

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

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

For a simple 2-parameter tool with an output schema, the description is complete: it covers purpose, path scope, overwrite semantics, and undo risk. It does not need to explain return values because an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by explaining 'sobrescribir=True' as the explicit overwrite opt-in and the ruta constraint as being under COPPELIA_DIRECTORIO_ESCENAS. The meaning of ruta as the target file path is implied by 'Guarda la escena actual en un .ttt'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description opens with 'Guarda la escena actual en un .ttt', naming a specific verb, resource, and output format. It is clearly distinguishable from siblings like cargar_escena and cerrar_escena, which are load/close operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives clear context for use (saving the current scene to a .ttt) and explicit operational guidance: it writes only under COPPELIA_DIRECTORIO_ESCENAS and refuses to overwrite unless sobrescribir=True. However, it does not explicitly name alternatives or when-not-to-use conditions.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for disclosing behavior. It only states 'starts the simulation' but does not explain potential side effects (e.g., resets simulation time, throws error if already running, requires an active scene), nor does it mention return values or errors. This minimal disclosure falls short for an action tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, concise sentence with no redundant words. It is front-loaded and directly communicates the action. Perfect conciseness for a parameterless tool.

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

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

The description is extremely minimal. It does not mention any side effects, error conditions, or interaction with other tools (e.g., must load a scene first). With no annotations and no output schema details provided in context, the description lacks sufficient information for an agent to fully understand the behavior and prerequisites. Given the simple action, a bit more context (e.g., 'starts or resumes simulation from current state') would be expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema coverage is effectively 100%. There is nothing for the description to add about parameters. The baseline for 0-parameter tools is 4, and the description doesn't need to elaborate on parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the action: 'Inicia la simulación en CoppeliaSim' (starts the simulation in CoppeliaSim). It specifies a specific verb ('inicia') and resource ('simulación'), and the purpose is distinct from sibling tools like detener_simulacion (stop), pausar_simulacion (pause), and estado_simulacion (state).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is provided about when to use this tool versus alternatives. There's no mention of prerequisites (e.g., a scene must be loaded), conditions (e.g., simulation must be stopped or paused), or any indication that this should be called before others. The description simply states the action without context.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries some burden. It indicates a read operation (implying no side effects) and lists the output fields, but does not mention potential errors, permission requirements, or whether the sensor must exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, concise sentence that directly conveys the tool's function and expected output. No unnecessary words or redundancy.

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

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

Given the lack of output schema and annotations, the description is too minimal. It does not clarify how to interpret the parameter, what the output looks like in detail, or any error conditions. The tool is simple, but the description leaves gaps for successful usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'sensor' has no description in the schema, and the tool description does not explain what it represents (e.g., name, ID, or how to specify it). With 0% schema coverage and no compensation in the description, parameter semantics are inadequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool reads a proximity sensor and specifies the output: detection status, distance, and point. It distinguishes from sibling 'comprobar_sensor_proximidad' by using 'lee' (reads) and detailing what data is returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is provided on when to use this tool over alternatives like 'comprobar_sensor_proximidad'. The description does not mention conditions, prerequisites, or context for using this read operation.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It usefully explains that matching is case-insensitive, that the filter applies to the path, and that unfiltered results are numerous. This goes beyond the schema, though the interaction with the 'limite' parameter is not fully clarified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loaded: one sentence establishes purpose, and the next gives filter semantics and a practical warning. Every sentence contributes useful information with no filler.

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

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

The output schema covers return values, so that is not a gap. The core listing behavior and filter are well described, but the 'limite' parameter is undocumented and its default appears inconsistent with the 'hundreds' claim, leaving a material gap for an agent trying to control result size.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for both parameters. It explains 'filtro' well with examples and case-insensitivity, but 'limite' is never mentioned or described. Additionally, saying unfiltered results are 'hundreds' sits awkwardly with the schema default of 40 for 'limite', leaving result-size behavior unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states a specific action and resource: it lists .ttm models from the CoppeliaSim-installed library. This distinguishes it from sibling tools like listar_objetos, which presumably operate on the current scene rather than the model library.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives explicit practical guidance: use a filter to narrow results by path substring and avoid overly large result sets without one. It does not explicitly contrast with alternatives such as listar_objetos, but the context of use is clear and no misleading exclusions are present.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. 'Lista' implicitly indicates a read-only operation, and the 'tipo' enumeration adds filtering behavior. However, it does not disclose prerequisites (e.g., an open scene) or possible error conditions, leaving some behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two sentences: the first states the purpose, the second enumerates parameter options. Both are concise and front-loaded, with no wasted words.

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

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

For a simple listing tool with one optional filter and an output schema, the description is adequate. It covers purpose and parameter values. It could optionally mention that a scene must be loaded before use, but this is a minor gap given the low complexity and existing output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so by listing all allowed values for 'tipo' ('todos', 'shape', 'joint', 'dummy', 'sensor', 'camara', 'luz', 'path'), giving agents the necessary vocabulary. It does not explain each value's exact meaning, but the labels are mostly self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's function: 'Lista los objetos de la escena actual con su ruta y su handle.' It uses a specific verb ('Lista'), a resource ('objetos de la escena actual'), and specifies the output details ('ruta y handle'), distinguishing it from sibling tools like eliminar_objeto or fijar_posicion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies the tool is used for listing objects and gives filtering context through the 'tipo' values ('todos', 'shape', 'joint', etc.). It does not explicitly mention alternatives, but none of the sibling tools serve the same listing purpose, so the context is clear. No exclusions are stated.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It indicates a read operation but does not disclose return format, units, error conditions, or prerequisites such as a running simulation. The description adds minimal value beyond the tool name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple getter, though it lacks semantic depth covered in other dimensions.

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

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

Although an output schema exists, the description still fails to provide necessary context for a tool with no annotations and zero parameter schema coverage. It does not explain usage prerequisites or any additional operational details, making it incomplete for smooth agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter 'junta' has no schema description (0% coverage). The phrase 'en una articulación' merely restates the parameter name/title and does not clarify identifier format, accepted values, or how the joint should be referenced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the action ('Lee' - reads) and the resource ('fuerza o par medido en una articulación'). This distinguishes it from sibling tools like obtener_posicion_junta and fijar_velocidad_junta.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is given on when to use this tool versus alternatives. The use case is implied by the name and description, but no exclusions or alternative tool references are provided.

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

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 only mentions the return format (Euler angles in radians) but does not indicate whether the operation is read-only, whether it can fail, or how the 'relativo_a' parameter affects the result. The absence of any mention of side effects or error conditions leaves significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, concise sentence that delivers the core purpose without unnecessary words. It is front-loaded with the action and output, making it quickly scannable. However, given its brevity, it omits critical details, slightly reducing the score for structural completeness.

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

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

The tool has a simple function, but the description is incomplete given the presence of two parameters and an output schema. It does not explain parameter semantics or usage context, and while the output schema covers return values, the description offers no behavioral or usage guidance. For a tool with no annotations, this is insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fails to explain either parameter. It does not clarify that 'nombre' is the object name or that 'relativo_a' denotes the reference frame (with default 'mundo'). The description does not compensate for the schema's lack of parameter descriptions, leaving semantic meaning entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the verb 'Devuelve' (returns) and the resource 'orientación de un objeto' (object orientation), specifying the output format as Euler angles in radians. This differentiates it from sibling tools like 'fijar_orientacion' (set orientation) and 'obtener_posicion' (get position), making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides no guidance on when to use this tool versus alternatives, such as when to prefer 'obtener_orientacion' over other getters or the setter 'fijar_orientacion'. The usage is implied but not explicitly stated, and there is no mention of exclusions or prerequisites.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full burden. It discloses the return format (coordinate array), units (meters), and the meaning of relativo_a. However, it does not describe behavior for nonexistent objects, invalid paths, or other error conditions, and it does not explicitly state that the operation is read-only beyond the verb 'devuelve'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two concise sentences with no filler. The main purpose is front-loaded, and the second sentence provides essential parameter detail about relativo_a. Every word earns its place.

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

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

For a simple two-parameter getter with an output schema, the description covers the core behavior, return format, and relative-to semantics. It is adequate, though it could be more complete by specifying error behavior and the exact path syntax for 'nombre'. Overall, it provides enough context for an agent to invoke the tool correctly in most cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains relativo_a values ('mundo' or an object path like '/Cuboid') and adds units. However, 'nombre' is only implicitly described as an object name via 'de un objeto'; no path syntax or format for 'nombre' is provided beyond the schema field title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's purpose: 'Devuelve la posición [x, y, z] de un objeto, en metros.' It uses a specific verb (devuelve), identifies the resource (posición de un objeto), and specifies the output format. This distinguishes it from siblings like fijar_posicion (setter) and obtener_posicion_junta (joint-specific position).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied: the tool is a getter for object positions, so the agent can infer when to use it. However, there is no explicit guidance about when to prefer this over obtener_posicion_junta or fijar_posicion, and no mention of alternatives or exclusions.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, but the description clearly indicates a read operation without side effects. Units are specified, but potential error conditions or return format are not mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Single concise sentence with no redundant text, effectively communicating the purpose and units.

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

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

Provides unit information indicating return type, but lacks explicit output schema or detailed behavior. Sufficient for a simple getter but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter 'junta' is not described in the schema or tool description beyond the name, leaving the expected format (e.g., joint name) implicit. Minimal guidance for the value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

Clearly states it reads a joint's position and specifies units (radians for revolute, meters for prismatic), distinguishing it from sibling tools like orientation and object position.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Implies usage for querying joint positions, but does not explicitly contrast with alternatives like obtaining orientation or setting position. The units and purpose make the context clear.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the side effect of leaving the simulation in step mode, states that the simulation will only advance when requested afterward, and warns that a waiting step-mode simulation may appear frozen.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured and front-loaded: the core action and return value come first, followed by a concise rationale, then side-effect and cleanup guidance. Every sentence serves a distinct purpose, and there is no redundant repetition of schema details.

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

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

For a one-parameter tool with no annotations and an existing output schema, the description is complete. It explains what the tool does, why to use it, how it changes simulation mode, and what to do afterward. The return format is covered by the output schema, so its absence in the description is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only the parameter name 'pasos', type integer, and default 1, with no property description. The description adds meaningful semantics by explaining that 'pasos' is the exact number of simulation steps to advance. It does not discuss constraints like positivity, but for a single simple parameter this is a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description opens with a specific action and resource: 'Avanza la simulación un número exacto de pasos y devuelve el tiempo.' It clearly communicates that this tool advances a simulation by a fixed number of steps and returns the time, and it is easy to distinguish from related simulation-control tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly explains when to use the tool: when repeatable, deterministic measurements are needed because free-running simulation timing is not reproducible. It also names 'detener_simulacion' as the cleanup call and explains the consequence of not calling it, which is strong practical guidance.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No side effects or behavioral details are disclosed, such as whether the simulation state is preserved, if it can be resumed via another tool, or if it triggers any events. This lack of transparency may lead to incorrect expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, concise sentence that directly states the action. It is appropriately sized and front-loaded, with no unnecessary words.

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

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

Given the simplicity of the tool (no parameters, low complexity), the description is minimal but adequate. However, it lacks context about potential error states or interaction with other tools (e.g., must be running), making it incomplete for robust agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty (0 parameters), and schema coverage is 100%. According to rubric, baseline is 3. The description adds no parameter information, but none is needed since there are no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's action: 'Pausa la simulación' (Pause the simulation). This is unambiguous and distinguishes it from sibling tools like iniciar_simulacion (start) and detener_simulacion (stop).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description does not provide any guidance on when to use this tool, such as prerequisites (e.g., simulation must be running) or conditions for failure. Without annotations, this information is absent, making usage ambiguous.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It implies a read-only operation (returns a value) but does not mention potential side effects, error conditions, or dependencies like simulation state. However, for a simple getter, this is minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single concise sentence that immediately states the tool's purpose and unit of measurement. No filler, perfectly front-loaded.

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

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

Given the simplicity (no params, clear return value in seconds) and the presence of an output schema, the description is sufficiently complete. It doesn't explain potential failure modes, but for a trivial getter this is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description needs to explain none. Per the rubric, 0 params gives a baseline of 4. The description correctly omits parameter details, and there is no ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

Clearly states it returns the elapsed simulation time in seconds. The verb 'Devuelve' and resource 'tiempo de simulación transcurrido' are specific, and it distinguishes itself from siblings like 'estado_simulacion' by focusing specifically on time.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is provided on when to use this tool versus alternatives, or any prerequisites such as requiring a running simulation. The description is purely functional with no context or exclusions.

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