arc-world-engine-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct purposes, such as creating/updating/removing actors, adding effects by trigger type, and managing snapshots. The only minor overlap is between the general add_rule and the specific add_*_effect tools, but descriptions clarify their scopes.
Naming Consistency4/5
Tool names mostly follow a consistent verb_noun snake_case pattern (create_actor, update_actor, remove_actor, add_rule). Minor deviations include merge_actors using plural while other actor operations are singular, and rollback lacking a noun object.
Tool Count4/5
18 tools is on the higher side but each addresses a distinct aspect of the world engine: world setup, actor management, simulation, effects, and state inspection. No tool seems redundant, and the count is appropriate for the complex domain.
Completeness5/5
The tool surface covers the full lifecycle of world management: creating worlds, loading static maps, actor CRUD, simulation, rule/effect binding, observation comparison, and snapshot rollback. There are no obvious gaps that would prevent an agent from completing common tasks.
Average 3.1/5 across 18 of 18 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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 Apache 2.0.
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 must carry the full burden of behavioral disclosure. It mentions the trigger event but does not explain whether the effect is additive, what the effect string format is, or how target_actor_id and args modify the behavior. Side effects or prerequisites are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient and front-loaded. However, it lacks any structural elements such as parameter lists or usage notes, making it under-specified for a tool with four parameters.
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 four-parameter schema and the absence of annotations, the description is far from complete. It does not cover return values, effect behavior, or parameter interactions, leaving significant ambiguity for the agent.
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%, so the description needs to explain the parameters. It only mentions 'effect' and 'source actor' without elaborating on their values or expected formats. 'target_actor_id' and 'args' are completely omitted, leaving the agent guessing.
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 applies an effect triggered by ACTION6 clicking the source actor, using a specific verb and resource. It distinguishes this tool from siblings like add_timer_effect by naming the click trigger. However, 'ACTION6' is an unexplained constant that slightly reduces clarity.
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 add_collision_effect or add_timer_effect. It only states what happens (an effect applies on click) without any contextual or exclusionary information.
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. It discloses one behavioral trait (timing based on action ticks, not wall-clock time) but fails to explain key behaviors like repetition semantics, cancellation, persistence, or side effects. The parameters 'every' and 'phase' suggest periodic behavior but are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise at one sentence, but it is under-specified for the tool's complexity. While front-loaded with the core concept, it omits crucial details, making it more of a teaser than a complete specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, three required, no annotations, no schema descriptions, and a context with many sibling tools, the description is severely incomplete. It doesn't explain how to construct arguments or what to expect on invocation, making it difficult for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level explanations. It doesn't clarify what 'effect' means, the role of 'every', 'phase', 'args', or the default values. The only implicit hint is that the effect applies to an actor.
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 applies an actor effect on discrete action ticks, distinguishing it from wall-clock-based effects. However, it doesn't specify the nature of the effect or how it relates to sibling effects like add_collision_effect or add_click_effect. The verb 'apply' is specific, and the resource is the actor, but the tool's name already conveys a timer effect.
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?
It provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention coexistence with other effect tools or prerequisites. The only clue is 'discrete action ticks' which implies a use case, but there's no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears full responsibility for disclosing behavioral aspects. It only states the binding action without explaining side effects, whether existing bindings are overridden, the meaning of collision_policy, or any potential errors. This leaves significant behavioral ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary action. It avoids verbosity, but its brevity comes at the cost of important details. It is appropriately concise for the information it conveys, though it could have added contextual remarks without becoming bloated.
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 two parameters, no annotations, and an output schema, but the description is minimal. It does not explain return values (though the output schema may cover that), nor does it offer enough context about when to use this tool, how it interacts with existing actor configurations, or the behavioral meaning of collision_policy. The presence of many sibling tools increases the need for richer contextual guidance, which is absent.
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 adds almost no meaning to the parameters. It names 'ACTION1-4' and 'movement', but does not clarify the role of actor_id or collision_policy. The collision_policy parameter is completely opaque, and the description fails to compensate for the lack of schema descriptions.
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 action: binding ACTION1-4 to directional movements for an actor. It uses a specific verb and resource, and the purpose is distinguishable from sibling tools like add_rule or update_actor. However, it does not explicitly mention the optional collision_policy parameter, leaving some ambiguity about the full scope.
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. It does not mention prerequisites, typical use cases, or situations where another tool would be more appropriate. The only implicit hint is the directional movement focus, but this is not sufficient guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions 'merge' implying mutation, but does not explain what happens to the merged actors (e.g., are they deleted?), reversibility, permissions, or any side effects. The phrase 'using their rendered world topology' is vague and does not clarify behavioral impact.
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 is front-loaded with the action ('Merge actors') and avoids unnecessary words. It is appropriately sized, though it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, no parameter explanations, and an output schema that is not described, the description is severely incomplete. It does not mention return values, side effects on other actors, or any usage context. This is a very sparse description for the complexity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, actor_ids (array of integers), and the description adds no explanation about the parameter. It does not clarify the order of IDs, what 'first ID' refers to (e.g., first in array), or the expected format. With 0% schema description coverage, the description must compensate but fails to do so.
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 ('Merge actors') and identifies the target ('the first ID'), and it distinguishes itself from sibling tools like split_actor. However, the phrase 'using their rendered world topology' adds ambiguity about what topology means and how it affects the merge, so it is not perfectly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like split_actor or update_actor. The description only implies a merge operation but does not state preconditions, scenarios, 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.
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. It discloses the partial-update behavior ('only the provided') but leaves critical details ambiguous: what happens when fields are null vs omitted, whether missing actor_id causes an error, and what the response contains. This opacity is significant for a mutation tool with 11 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is acceptable for a simple tool, but it under-specifies a complex tool with 11 parameters. It lacks a summary of return behavior or parameter categories. Every word is used, but significant information is missing, so it does not fully 'earn its place'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no annotations, and zero schema descriptions, the description is insufficient. It should explain partial-update semantics more explicitly, list the field groups, mention error handling for unknown actor_id, and possibly reference the output schema. The output schema exists but is not acknowledged. The tool is moderately complex, and the description leaves too many gaps.
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 undocumented parameters. It merely groups fields into 'state' and 'transform' without mapping which parameters belong to which category or explaining units/formats (e.g., color integer meaning, rotation degrees, properties map). The schema only lists titles and defaults, leaving meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as an update to an actor and specifies that only provided fields are affected. It distinguishes from create_actor by focusing on modification, but the phrase 'generic actor state and transform fields' is somewhat vague and does not explicitly mention 'existing actor' or the actor_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like create_actor or remove_actor. The description implies a partial update but does not state prerequisites (e.g., that the actor must already exist) or contrast with sibling tools. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the core creation action and a cells format note, but says nothing about side effects, return values, constraints, or what happens if an actor with the same name already exists. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the main verb, which is good for conciseness. However, it omits essential information for a tool with 10 parameters, making it under-specified rather than appropriately concise. The single-cell format note is useful but does not justify the lack of detail for other important parameters.
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 tool's complexity (10 parameters, no annotations) and the existence of an output schema, the description still leaves major gaps: what an actor is, the coordinate system, the meaning of z/visible/pushable/properties, and how this tool relates to siblings. It is incomplete for a tool of this complexity.
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 elaborates on the 'cells' parameter format, leaving the other 9 parameters unaddressed. Schema description coverage is 0%, so the description does not compensate for missing parameter meanings. Even the cells format note is partially redundant with the schema, which already defines the array structure.
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 function with 'Create a generic actor', using a specific verb and resource. It distinguishes from sibling tools like update_actor or remove_actor by the create verb, but doesn't explicitly differentiate 'generic' from specialized actors, so it loses a point for lack of explicit sibling differentiation.
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?
No explicit when-to-use guidance or alternative tool mentions. The phrase 'generic actor' implies it is the base creation tool, but the description does not say when not to use it, nor does it mention alternatives like load_static_map or specialized creation tools. Usage context is only implied, 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?
Without annotations, the description must disclose side effects and constraints. It mentions the 64x64 cell limit but does not explain error handling, coordinate semantics, or reversible effects, leaving significant behavioral ambiguity.
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 immediately states the core action and constraint. No filler or redundant information.
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 four required parameters and no annotations, the description is underspecified. It omits prerequisites, error behavior, and parameter details, making it insufficient for reliable invocation without additional 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 coverage is 0%, so the description must explain parameters. It maps x/y to 'camera origin' and width/height to 'viewport' and mentions the cell limit, but does not clarify coordinate units, valid ranges beyond the max, or edge cases, offering minimal semantic addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Set') and the resource (camera origin and viewport), with a specific constraint (up to 64x64 cells). It is distinct from sibling tools like create_world or get_world_state, though it lacks explicit comparative language.
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, or any context such as requiring an existing world or camera. The description only states the 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?
Annotations are absent, so the description bears the full burden of disclosing behavioral traits. It only mentions the mechanism ('partitioning local topology cells') without addressing effects, reversibility, permissions, or potential side effects, which is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy. It is well-structured and easy to read, though its brevity borders on under-specification. Since conciseness is about absence of waste, it earns a high score.
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 tool's complexity (nested parameter arrays, mutation semantics) and lack of annotations, the description is far from complete. It omits parameter semantics, behavioral effects, and usage context. The existence of an output schema relieves the need to describe returns, but other gaps remain significant.
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 hints that 'groups' relate to partitioning cells, but it doesn't explain the nested array structure or what integers represent. The actor_id is obvious from context, but the groups parameter remains poorly understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (split), the target (actor), and the method (partitioning local topology cells). This distinguishes it from sibling tools like merge_actors or update_actor, leaving no ambiguity about what the tool accomplishes.
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 any prerequisites or exclusion cases. The description only states what it does, not when to prefer it, so the agent receives no decision-making support.
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 full burden for behavioral disclosure. It only mentions the collision trigger and does not explain side effects, persistence, scope, or interaction with the world state. The presence of undeclared parameters like target_actor_id and args further underscores the lack of behavioral transparency.
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 directly states the core function. It avoids redundancy and is easy to parse. However, it is under-specified, which detracts slightly from its structural completeness, though this is partially captured 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?
The tool has 5 parameters, no annotations, and an output schema that is not shown. The description only covers the fundamental collision trigger, leaving parameter semantics, behavioral details, and expected outcomes ambiguous. This is insufficient for an agent to confidently select and invoke the tool, even if return values are covered by the unseen output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to compensate. While moving_actor_id, collider_actor_id, and effect are somewhat self-explanatory, the meaning of target_actor_id (with a large default value) and args is completely unspecified. The description adds no additional meaning beyond the parameter names.
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: 'Apply an effect when one actor collides with another actor or static map.' This uses a specific verb ('apply') and resource ('effect'), and the collision trigger clearly distinguishes it from sibling tools like add_click_effect and add_timer_effect.
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 context (collision events) but does not explicitly address when to use this tool versus alternatives or mention exclusions. Sibling tools exist for other trigger types, but no direct comparison or guidance is provided, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It only says 'compare' but does not explain what the comparison returns, whether it has side effects, or any prerequisites. This is a significant gap for a tool with no annotation coverage.
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 immediately communicates the action. Every word contributes meaning with no redundancy or filler.
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 lacks essential context such as when to use this tool (e.g., after setting a viewport), what the output indicates, or any behavioral constraints. The tool is simple but still under-described given the absence of annotations and parameter details.
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%, and the only parameter 'observed' has no schema-level description. The description adds the semantic cue that 'observed' represents the real ARC frame, which is helpful but does not fully explain the expected grid structure or format beyond the type definition.
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 'compare' and clearly identifies the resources: a real ARC frame and the model's current rendered viewport. This distinguishes it from sibling tools like set_viewport or get_world_state, which perform different actions.
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 mention when to use this tool, when not to, or any alternatives. It only states what it does, leaving the agent without guidance on selecting it over other tools.
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 the world is deterministic and empty, and mentions the color range 0-15, which adds some behavioral context. However, with no annotations, it fails to mention side effects such as overwriting an existing world, required setup, or the meaning of the background parameter, leaving 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, front-loaded sentence that efficiently conveys the core purpose without unnecessary fluff. While it is concise and well-structured, its brevity means it lacks important details, but the structure itself is good.
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?
Even with an output schema present, the description is too sparse for a tool with four parameters and no annotations. It does not explain parameter usage, side effects, or prerequisites, making it incomplete for an AI agent to invoke correctly.
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%, so the description must compensate by explaining parameters, but it does not. It only mentions raw ARC colors 0-15, which is not directly mapped to any specific parameter, leaving width, height, debug, and background unexplained.
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 an empty deterministic world using ARC colors 0-15, with a specific verb and resource. This distinguishes it from sibling tools like load_static_map, which loads a static map rather than creating an empty world.
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 this tool is used to initialize a new world by stating it creates an empty world, but it provides no explicit guidance on when to use it versus alternatives or any prerequisites. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions 'deterministic' and the ACTION6 coordinate handling, which adds some value. However, it does not disclose side effects, return values, or what other actions do, leaving significant ambiguity for a stateful simulation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the core purpose in the first sentence. It does not waste words, though the terse reference to 'ACTION6' assumes internal knowledge and could be slightly clearer.
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 operates in a simulation context with many sibling tools, but the description gives almost no context about when to invoke it, how it relates to other tools, or what the output schema represents. The ACTION6 reference is cryptic and unexplained, leaving the description incomplete for an agent to use 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?
Schema description coverage is 0%, so the description must compensate. It only explains that x and y are viewport click coordinates for ACTION6, leaving the meaning of the required 'action' parameter and the general x/y combo largely undefined. Partial coverage only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Advance one deterministic turn.' The verb 'advance' with the resource 'turn' is specific and clearly distinguishes it from sibling tools like add_directional_movement or update_actor.
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 (to advance a simulation turn) but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It discloses that the tool creates a full clone of the world, which is useful, but it does not mention side effects (e.g., overwriting existing snapshots, resource usage), return behavior, or snapshot lifecycle. Some context is present, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose without any unnecessary words or filler. Every word earns its place.
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?
In the context of a rich simulation toolset with many sibling operations, this description is too sparse. It does not explain how the snapshot relates to rollback operationally, whether multiple snapshots are allowed, or what the return value contains (though an output schema exists). The description leaves the agent without enough context to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the 'name' parameter at all. The agent is left without any explanation of what 'name' refers to, whether it must be unique, or what happens if omitted. The description entirely fails to compensate for the lack of schema documentation.
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 ('Clone') and resource ('the complete native world') and explicitly states the purpose ('for later rollback'), making it clear what the tool does and distinguishing it from sibling tools like rollback and create_world.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for later rollback' implies the tool should be used before changes that may need to be undone, but the description does not explicitly state when to use it versus alternatives like rollback or create_world. No exclusions or conditions 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 must carry the behavioral burden. It discloses two useful behaviors: invalid code is rejected with line/column errors, and legacy structured fields are still accepted. However, it does not mention whether the tool mutates state, whether there are side effects, or any permission requirements. Given the lack of annotations, this is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 100 words, front-loaded with the core purpose and then providing examples and error handling. Each sentence contributes unique information: syntax, examples, and error/rejection behavior. It is structured well with code blocks, though slightly dense.
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 has 21 parameters, three required, and no annotations. The description covers the core code-based usage and error behavior, and mentions legacy fields, but does not explain the overall context of rules (e.g., trigger/effect relationship, execution order, or how owner_actor_id and target_actor_id work). Given the complexity and lack of annotation support, the description is not fully complete, though it provides a solid starting point.
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 is the only source of parameter meaning. It effectively explains condition_code and effect_code with syntax examples, and hints at 'action' with ACTION6 coordinates. However, many legacy parameters (owner_actor_id, source_actor_id, condition_operator, etc.) are not explained. The description adds value but does not fully compensate for the low schema coverage.
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 opens with 'Attach actor ECE code', clearly identifying the tool's verb and resource. This distinguishes it from sibling tools like add_collision_effect or add_timer_effect, which target specific effect types. However, the term 'ECE code' is somewhat technical and may require prior context to fully understand.
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 provides concrete usage patterns through examples of condition_code and effect_code syntax. It implies this is the modern approach ('Legacy structured fields remain accepted'), but does not explicitly state when to choose this over sibling tools or when not to use it. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Restore' implies a mutation, but the description does not disclose that this operation overwrites current state, whether it is destructive, requires specific permissions, or what happens if the named snapshot does not exist. These are significant gaps for a state-altering tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. Every word contributes to understanding the tool's action and object, making it highly concise and front-loaded.
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 that this is a mutation tool with no annotations and an output schema (which partially relieves the need to explain return values), the description still lacks critical context: it does not explain that restoring a snapshot overwrites the current state, whether the operation is reversible, or how errors are handled. This leaves the tool's behavior in real-world scenarios poorly defined.
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 defines only one parameter, 'name', with no additional description. The tool description adds meaning by specifying that the name refers to a 'previously named native snapshot', clarifying the expected value. However, this is minimal additional context beyond the schema field title, so it does not fully compensate for the 0% schema description 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 uses the specific verb 'Restore' and clearly identifies the resource as 'a previously named native snapshot'. It distinguishes the tool from siblings like create_snapshot by implying it reverses an earlier action, making its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a snapshot has been previously created, but it does not explicitly state when to use it versus alternatives or mention edge cases (e.g., no existing snapshot). The 'previously named' phrase offers contextual guidance but lacks explicit exclusion or alternative references.
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. It states the tool 'returns' data, implying a read-only operation, but does not explicitly disclose that it has no side effects, whether it is safe to call frequently, or any performance implications. It also omits context about the meaning of 'hashes' or 'trace' and whether the returned data is a snapshot or live state. This is minimal transparency.
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 is front-loaded with the verb and lists all major output categories. Every word earns its place, and there is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (as indicated by context signals), the description need not detail return types. The summary of returned components (layers, actors, rules, hashes, trace, debug history) is sufficient for a simple, zero-parameter getter. It lacks usage context, but that is already scored separately and does not undermine completeness.
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 baseline is 4. The description does not need to explain parameter behavior, and the empty schema already confirms there are no arguments. The description adds value by indicating what the returned data includes, which indirectly clarifies that no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and names the exact resources: rendered layers, actors, rules, hashes, trace, and debug history. This clearly distinguishes it from sibling mutation tools like update_actor, remove_actor, and create_actor, making its 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 gives no guidance on when to use this tool versus alternatives. It does not mention that this should be used for inspecting state, nor does it reference compare_observation or create_snapshot as alternatives for state examination. Without such context, the agent must infer usage purely from the tool name and purpose.
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 burden. It discloses that the tool is destructive ('Replace') and that it does not create actors, which is useful. However, it does not mention other side effects, reversibility, or requirements, leaving gaps about the operation's impact on the world.
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 that conveys the core action and a key caveat in ten words. Every word is informative, with no redundancy.
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 operation is fairly simple and an output schema exists, but with no annotations and minimal parameter guidance, the description is incomplete. It lacks context about when the world must be initialized and how the replacement interacts with existing actors, making it barely adequate for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters. It only hints that 'colors' maps to the color layer and 'blocked' to the collision layer, but does not clarify the data structures (nested arrays, value domains) or how the parameters relate. This leaves the agent without enough information to construct valid inputs.
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 ('Replace') and identifies the resource ('static color and collision layers'), and explicitly distinguishes this tool from actor creation by stating 'without creating actors', which differentiates it from sibling tools like create_actor.
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 provides minimal usage guidance: it implies this tool is for map/layer replacement rather than actor creation, but does not explicitly state when to use it over alternatives or mention any prerequisites (e.g., a world must exist). The context is somewhat implied by the phrase 'without creating actors'.
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, the description carries the transparency burden. It discloses a critical side effect: automatic removal of ECE rules that reference the actor. However, it does not mention permanence, error behavior, or authorization requirements, though the cascade is well highlighted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the primary action and the key side effect. Every word contributes meaning, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with an output schema, the description is largely complete. It covers both the action and its cascade effect. The only minor gap is not stating that the actor must exist, but that is implied by a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for 'actor_id'. It does not explain how to obtain this ID or any constraints, leaving the parameter under-explained despite its simple name.
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 'Delete' with a resource 'actor' and adds a key differentiator: 'automatically remove ECE rules that reference it.' This clearly distinguishes it from sibling tools like update_actor and create_actor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'Delete', but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of restrictions or prerequisites. The description lacks exclusions such as what happens if the actor doesn't exist or if rules reference it in a complex way.
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:

[![arc-agi-3-world-model-lab MCP server](https://glama.ai/mcp/servers/junxiangyang0707-hash/arc-agi-3-world-model-lab/badges/card.svg)](https://glama.ai/mcp/servers/junxiangyang0707-hash/arc-agi-3-world-model-lab)

Score Badge

Copy to your README.md:

[![arc-agi-3-world-model-lab MCP server](https://glama.ai/mcp/servers/junxiangyang0707-hash/arc-agi-3-world-model-lab/badges/score.svg)](https://glama.ai/mcp/servers/junxiangyang0707-hash/arc-agi-3-world-model-lab)

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/junxiangyang0707-hash/arc-agi-3-world-model-lab'

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