coppeliasim-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Most tools are clearly distinct (simulation control vs object manipulation vs joint control vs sensors), with good disambiguation between leer_sensor_proximidad and comprobar_sensor_proximidad. However, there is slight potential confusion between obtener_posicion_junta and fijar_objetivo_junta, though their different verbs help.
Naming Consistency4/5
Names follow a consistent Spanish verb_noun pattern (e.g., fijar_orientacion, obtener_orientacion, crear_primitiva, eliminar_objeto). Minor deviation: listar_objetos vs. others use verbs like fijar/obtener/crear/eliminar; all are indicative, but there's a mix of imperative verbs without a strict pattern like 'obtener' vs 'leer' for reading sensor data.
Tool Count4/5
With 23 tools, the server is somewhat heavy but still warranted for a full robotics simulation API covering simulation control, scene management, object manipulation, joint control, and sensors. It edges toward the upper bound but each tool is purposeful, so it's not overly excessive.
Completeness4/5
The tool set covers core simulation lifecycle (start/stop/pause/status/time), scene and object management (load/close, list/create/delete, transform, parenting), joint control (set/get position, velocity, force), and proximity sensors (create, detect, check). Missing operations like object rotation in quaternions or scene saving are minor gaps that don't break workflows.
Average 3.6/5 across 22 of 23 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description 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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It 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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is 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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so there are no 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema 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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It adds useful behavioral details: the tool returns the object's path ('devuelve su ruta') and states that sizes and positions are in meters. However, it does not disclose potential side effects, prerequisites (e.g., an open scene), error conditions, or the mutating nature beyond the verb 'crea'. For a creation tool, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the action and return value, and the second provides essential value enumerations and units. Every sentence earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (7 parameters, no annotations, but an output schema), the description covers the core action and return value but omits crucial contextual prerequisites. For instance, it does not mention that a scene must be open (sibling tools 'cargar_escena' and 'cerrar_escena' suggest this is required). It also does not describe the exact format of the returned path or any failure modes. The description is adequate for simple cases but incomplete for an autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by enumerating allowed values for 'forma' and stating units for sizes and positions ('Tamaños y posición en metros'). However, it does not explain how 'tamano_x/y/z' apply to different shapes (e.g., whether for a sphere they represent radius or scale). The parameter names are self-explanatory, but the description adds limited semantic depth beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Crea una forma primitiva en la escena y devuelve su ruta' (Creates a primitive shape in the scene and returns its path). The verb 'crea' is specific, the resource 'forma primitiva' is defined, and the list of allowed shapes ('cubo', 'esfera', etc.) further clarifies the scope. This distinguishes 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for creating primitive shapes, and the list of shapes tells the agent what values are acceptable. However, it does not explicitly state when not to use this tool or mention alternative creation methods (e.g., 'cargar_escena' for loading a full scene, or 'crear_sensor_proximidad' for sensors). The context is clear but lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. '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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![coppeliasim-mcp MCP server](https://glama.ai/mcp/servers/KevinInoCol/coppeliasim-mcp/badges/card.svg)](https://glama.ai/mcp/servers/KevinInoCol/coppeliasim-mcp)

Score Badge

Copy to your README.md:

[![coppeliasim-mcp MCP server](https://glama.ai/mcp/servers/KevinInoCol/coppeliasim-mcp/badges/score.svg)](https://glama.ai/mcp/servers/KevinInoCol/coppeliasim-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KevinInoCol/coppeliasim-mcp'

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