Cavalry MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct operation (create, get, set, delete, etc.) with clear resource categories (layer, attribute, scene, composition). The catch-all run_script explicitly notes it's for cases where no specialized tool fits, reducing ambiguity. No two tools appear to serve the same purpose.
Naming Consistency4/5
All tools share the cavalry_ prefix and mostly use verb_noun (create_layer, get_attribute, save_scene). A few deviate: 'keyframe' and 'magic_easing' are noun-like commands rather than verb phrases, but the overall pattern is consistent enough.
Tool Count4/5
With 21 tools, the set is substantial but not bloated. It covers the primary workflow of creating, manipulating, animating, and rendering scenes. No redundant tools; each offers distinct functionality. Slightly heavy but appropriate for a professional design tool.
Completeness4/5
The tools cover scene lifecycle (open/save), layer CRUD, attribute reading/writing, animation (keyframes/easing), composition info, and rendering. Missing advanced features like undo or asset management, but the core workflows are fully supported. The run_script escape hatch fills niche gaps.
Average 3.7/5 across 21 of 21 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 says 'select', which is ambiguous—it does not clarify whether this changes the current selection, returns a value, or how it handles invalid layer IDs. This lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundancy or filler. It is front-loaded and every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the core operation adequately. However, it omits details about return values, edge cases like invalid IDs, or whether previous selections are replaced, which an agent would need for confident invocation. The lack of annotations and output schema makes this a moderate gap.
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 'layerIds' is fully described in the schema as 'Array of layer IDs to select', and the tool description adds no additional semantics beyond that. With 100% schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Select'), the resource ('layers in Cavalry'), and the method ('by their IDs'). It is clear and specific, distinguishing it from sibling tools like cavalry_get_selected_layers (which reads the current selection) and cavalry_get_scene_layers (which lists layers), though it does not explicitly name alternatives.
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 related tools such as cavalry_get_selected_layers or cavalry_set_attribute. It lacks any context about prerequisites, exclusions, or alternative approaches, leaving the agent to infer usage.
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 that a scene file is opened, without mentioning side effects, prerequisites, failure modes, or whether the current scene is replaced. This is minimal and lacks useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and clear, though it could potentially elaborate on behavior without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple file-opening tool with one well-documented parameter, the description conveys the core purpose. However, it omits any detail about what happens after opening, return values, or integration with the rest of the Cavalry workflow, making it minimally acceptable.
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 already fully describes the single parameter (`filePath` as an absolute path to the .cv file), and the description adds no additional meaning. With 100% schema coverage, the baseline of 3 is appropriate.
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 ('Open') and resource ('Cavalry scene file (.cv)'), clearly indicating the tool's function. It distinguishes itself from siblings such as cavalry_save_scene and cavalry_run_script by focusing on loading an existing scene file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as when to use cavalry_open_scene before other scene manipulation tools. No exclusions or alternative recommendations are provided, leaving usage context entirely implied.
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 disclosing behavioral traits. It does not explain what happens to the duplicate's properties, naming, position, or whether it is a deep copy. It also does not state whether the tool returns the new layer's ID or modifies the scene state beyond duplicating. This is a significant gap for a mutation-style 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, front-loaded sentence with zero wasted words. It immediately states the action and object, achieving maximum conciseness while remaining clear.
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 with one well-documented parameter, but it lacks annotations and an output schema. The description does not explain the return value (if any) or the side effects on the scene, which are important for an agent to use the tool correctly. It is minimally viable but has clear gaps in completeness.
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 covers 100% of the single parameter (layerId) with a clear description. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate. No further semantic enrichment is needed given the parameter is fully documented in the input 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 'Duplicate a layer in the scene' uses a specific verb (Duplicate) and a clear resource (a layer), making the purpose immediately obvious. It clearly distinguishes from sibling tools like 'delete_layers' or 'create_layer' by specifying the duplication action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions. The description is a single statement of functionality without contextual usage advice. An agent receives no help in deciding whether duplication is appropriate over other layer operations.
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 does not reveal whether setting a keyframe overwrites existing ones, affects only the specified attribute, or requires particular layer types or permissions. This lack of detail for a mutation tool is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of unnecessary words. It immediately conveys the essential operation without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema fully documenting parameters, the description lacks context about side effects, return values, or error behavior. With no output schema and no annotations, a simple statement of intent is insufficient for an agent to fully anticipate invocation outcomes.
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 documentation covers 100% of the parameters, including an example for the attributes object. The description adds minimal meaning beyond restating that it sets a keyframe, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set), the resource (a keyframe on a layer attribute), and the specific condition (at a specific frame). This effectively distinguishes the tool from siblings like cavalry_set_attribute and cavalry_set_current_frame, which have different purposes.
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 for keyframe animation but does not explicitly mention when to choose this tool over alternatives such as cavalry_set_attribute. No exclusions or conditions are stated, leaving the decision to the agent's 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 behavior. It does not mention side effects, return values, permission requirements, or reversibility of adding a dynamic attribute. The type list is useful but does not compensate for the lack of behavioral context for a mutating 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, front-loaded sentence that immediately states the action and resource, followed by a concise list of types. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with fully described parameters, the description covers the core purpose. However, with no output schema and no annotations, it lacks guidance on when to use it and what behavioral side effects to expect, leaving gaps in completeness.
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 coverage is 100%, with all three parameters having descriptions. The description only repeats the allowed types already listed in the schema, adding no extra parameter-level meaning. Baseline 3 is appropriate since the schema carries the semantic weight.
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 'Add a dynamic attribute to a layer' with a specific verb and resource. It also provides an example context ('e.g., on a JavaScript Utility') that helps distinguish this from a generic set attribute operation. This is specific enough to differentiate from sibling tools like cavalry_set_attribute.
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 gives an example use case ('e.g., on a JavaScript Utility') but does not explicitly state when to use this tool versus alternatives like cavalry_set_attribute. There is no when-not guidance or mention of alternative tools, so usage is implied rather than 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, so the description carries the full burden of behavioral disclosure. It merely states deletion without warning about irreversibility, potential cascading effects, or what happens if layer IDs are invalid. This is a significant transparency gap for a destructive 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 with no superfluous words. It is front-loaded with the action verb and resource, making it easy to parse.
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 (one parameter, no output schema) and lack of annotations, the description is minimally adequate but leaves out important context such as the destructive nature and any return information. It is not as complete as it could be for a delete operation.
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 100% with a clear parameter description ('Array of layer IDs to delete'). The tool description adds no additional meaning beyond that, but the baseline for high coverage is 3, which is appropriate here.
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: 'Delete layers from the Cavalry scene by their IDs.' It uses a specific verb (delete), a specific resource (layers in a Cavalry scene), and the method (by IDs), which distinguishes it from sibling tools like cavalry_create_layer or cavalry_set_attribute.
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 operation, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or edge cases. For a simple delete operation, the context is somewhat apparent, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Render the current frame as a PNG file' and does not mention whether the file is overwritten, what happens on failure, or any requirements such as absolute path or directory creation. This is a significant gap for a file-writing 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 focused sentence with no filler or redundancy. Every word adds meaning, and it front-loads the core action and output format.
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 schema covers parameters, but the lack of annotations and behavioral details (e.g., overwrite behavior, required directory existence, error handling) leaves the description somewhat incomplete for an agent to anticipate side effects.
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 fully describes both parameters: filePath is an absolute output path and scale is a percentage with a default. Since schema coverage is 100%, the description adds no extra semantic value beyond the schema, so the baseline score of 3 is appropriate.
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 ('Render') with a clear resource ('current frame') and output format ('PNG file'). It is distinct from sibling tools like save_scene or set_current_frame, making its purpose immediately understandable.
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 states what the tool does but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. Usage context is implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions 'save' but doesn't state whether it overwrites the existing file, whether it requires an already-saved scene, or what happens if the file is new. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, immediately stating the action and the optional parameter. 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?
The description covers the core purpose and the optional parameter, but given the absence of annotations, it omits important behavioral details like overwrite semantics or file path handling. It is minimally sufficient for a simple tool but not fully complete.
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 already describes the filePath parameter fully ('Optional file path for Save As. Omit to save in-place'). The description merely echoes this concept, adding no meaningful extra 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 states the verb 'Save' and the resource 'current Cavalry scene', clearly distinguishing from siblings like open_scene or render_png. It also correctly identifies the optional save-as behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (save the current scene) but doesn't explicitly contrast with alternatives or state when to use it. No exclusions or conditional guidance 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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'read', which implies a non-mutating operation, but lacks details on error behavior (e.g., invalid attrPath), return value type, or any dependencies. The minimal phrasing does not disclose operational caveats.
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 unnecessary words. It immediately tells the reader what the tool does and earns every word, making it 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?
Given the tool's simplicity and that both parameters are documented, the description is mostly complete. It lacks an explicit mention of the return format, but 'read the value' implies the returned data. No output schema exists, but the tool's simplicity and the clear purpose cover most contextual needs.
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 description coverage is 100% (both 'layerId' and 'attrPath' have descriptions), so the baseline is 3. The description does not add additional meaning to the parameters beyond what the schema already provides; the examples in the schema ('position.x', 'fontSize') are already helpful.
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 (read) and resource (attribute from a layer). It distinguishes itself from sibling tools like cavalry_set_attribute (write) and other getters (e.g., cavalry_get_scene_layers) by the specific resource type. The verb 'read' immediately signals a non-mutating operation.
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 for reading an attribute value, but does not explicitly state when to use this tool versus alternatives. No exclusions or prerequisites are mentioned (e.g., needing an active connection or valid layer). The usage context is inferred from the purpose, but there is no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the action but does not mention potential side effects, return values, or constraints, though for a simple setter this 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, well-structured sentence with no superfluous words, immediately delivering the core action.
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 setter with no output schema, the description adequately conveys the tool's function. It lacks information about return behavior or error cases, but these are not critical for such a basic operation.
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's 'specific frame' aligns with the schema's 'Frame number to jump to', adding no extra semantic detail. Since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('playhead') within the timeline, clearly distinguishing this from sibling tools like cavalry_keyframe or cavalry_get_composition_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives; it simply states the action without context or exclusions, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully describe behavior. It does not mention side effects such as overwriting existing connections (the force parameter), whether the operation is reversible, or what happens in case of conflicts. This is a significant gap for a connection-wiring 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 two sentences, front-loaded with the main action, and contains no filler. Every word contributes to understanding the tool's purpose.
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 provides essential purpose and a usage tip, but lacks behavioral details such as overwrite behavior, failure semantics, and return values. For a 5-parameter tool with no annotations and no output schema, it is adequate but has clear gaps.
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 covers 100% of parameters with detailed descriptions, including the tip about using 'id' for sourceAttr. The description repeats this tip without adding new semantic information, so it does not elevate beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Connect an output attribute to an input attribute between layers.' This clearly identifies the tool's purpose and distinguishes it from siblings like cavalry_set_attribute (which sets a direct attribute) and cavalry_get_attribute (which reads).
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: it is for connecting attributes between layers. It also gives a practical tip about using 'id' as the outAttr for the main output. However, it does not explicitly contrast with alternatives or state when not to use this tool.
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 only states the action (create) and does not mention side effects such as scene modification, layer selection after creation, error handling for invalid layer types, or any prerequisites. The description adds minimal behavioral context beyond the action itself.
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 with the core purpose: 'Create a new layer in the Cavalry scene.' The long list of layer types is directly useful and not redundant. No extraneous words or filler are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter create operation without an output schema, the description covers the purpose and layer types adequately. However, it lacks behavioral details such as whether the new layer is selected, if the scene must be open, or what the function returns. With no annotations, these gaps prevent the description from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, providing a baseline of 3. The description adds significant value by listing common layer types (basicShape, textShape, null, etc.), which enriches the layerType parameter beyond the schema's few examples. This helps the agent select valid values without additional lookups.
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: 'Create a new layer in the Cavalry scene.' This uses a specific verb and resource, distinguishing it from sibling tools like duplicate_layer and delete_layers. The enumeration of common layer types further clarifies the scope of creation.
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 is for creating new layers, but it does not explicitly state when to use this tool versus alternatives like duplicate_layer. There are no exclusions or references to sibling tools for comparison. Usage is implied through the verb 'create' and the layer type list, but explicit guidance is absent.
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 must carry the full burden of behavioral disclosure. It simply states what the tool does without mentioning return format, coordinate system, or any side effects. Since this is a get operation, the read-only nature is implied, but no additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant fluff. It front-loads the key function and includes a useful hint about positioning. Every word contributes value.
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 with one parameter and no output schema. The description covers the action but does not explain what the bounding box represents (e.g., units, coordinate system) or the return structure. Without annotations or an output schema, this leaves some uncertainty, but the low complexity prevents a lower score.
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 100% coverage with a single parameter 'layerId' described as 'The layer ID'. The description adds no further meaning to the parameter, but the baseline is 3 due to high schema coverage. No gap exists in parameter understanding.
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 function: 'Get the bounding box of a layer'. It specifies the resource (layer) and the operation (get bounding box), distinguishing it from sibling tools like get_attribute or get_scene_layers. The parenthetical 'useful for positioning' adds context without ambiguity.
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 phrase 'useful for positioning' provides a clear use case, implying when to use the tool (when positioning elements). However, it does not explicitly mention when not to use it or alternatives, so it falls short of a full 5 but provides more than just an implied usage.
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 only restates the core purpose ('Get the currently selected layers') and does not disclose such things as what happens when nothing is selected, whether a connection to Cavalry is required, or whether the returned data is a list of names or objects. This lack of context makes it hard for an agent to predict tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the tool's function without any filler or redundancy. It is front-loaded and easy to scan.
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, but the description is minimal. There is no output schema, so the description should ideally convey what 'layers' means (e.g., layer IDs, names, objects) or mention edge cases like an empty selection. The current description is adequate but leaves some ambiguity, so it's a passable but incomplete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (zero parameters), and schema description coverage is 100% vacuously. The baseline for zero parameters is 4, and the description correctly does not invent or mention parameters, so it fully aligns with the schema. No extra parameter details are needed.
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 ('Get') with a clear resource ('currently selected layers') and the scope is distinct from siblings like get_scene_layers. It immediately tells the agent exactly what the tool does, matching the tool name without ambiguity.
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 by the name and comparison to siblings like get_scene_layers (to get all layers) or select_layers (to modify selection). However, there is no explicit statement of when to choose this over alternatives, nor any mention of prerequisites or conditions.
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 should disclose behavioral traits such as mutation, destructiveness, or side effects. It only says 'Apply' without stating whether this modifies existing keyframe data, replaces easing, or requires specific conditions. The list of easing types adds some context, but key safety and behavior details are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action, the second lists supported easing types. Every word is purposeful, and the key action is front-loaded. No redundancy or filler.
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 no annotations or output schema, the description must carry more weight. It covers the core purpose and parameter domains, but lacks behavior details (e.g., whether it mutates, requires existing keyframes, or returns anything). The schema fills parameter semantics, but contextual gaps remain for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by enumerating all accepted easing types, which effectively provides an enum-like set for the easingType parameter. This is helpful beyond the schema's generic 'Easing type' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Apply Magic Easing') on a specific resource ('keyframed attribute'), and the list of easing types clarifies the tool's distinct functionality. This clearly distinguishes it from sibling tools like cavalry_set_attribute or cavalry_keyframe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through 'keyframed attribute' — the tool is meant for keyframed properties — but there is no explicit guidance on when to use this tool over alternatives, nor any exclusions or prerequisites. The description does not mention whether an existing keyframe is required or how it interacts with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Get information,' which implies a read-only operation but does not explicitly confirm no side effects, error behavior (e.g., if no composition is open), or return format details. The listed fields (resolution, frame range, FPS) hint at output but fall short of full 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, front-loaded sentence that immediately states the action and resource, then enumerates the key data points. It contains no filler or redundant wording, making it exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool, the description covers the important return values (resolution, frame range, FPS). Since there is no output schema, it does provide some return information, but it could be more explicit about the format or units (e.g., pixel dimensions, frame numbers). Overall, it is adequately complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameters, and the empty input schema is sufficient. No additional semantic value is required or provided.
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: 'Get information about the active composition' with specific examples (resolution, frame range, FPS). The verb 'get' and resource 'composition' differentiate it from sibling tools like cavalry_get_scene_layers or cavalry_get_attribute, which target other resources.
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 by naming 'active composition,' but it does not explicitly state when to use this tool versus alternatives like cavalry_get_scene_layers or cavalry_get_attribute. There is no mention of exclusions or conditions, leaving usage guidance implicit rather than 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?
No annotations are provided, so the description carries the full burden. It explains the dot-notation path syntax and gives examples, which is useful, but it does not disclose side effects such as whether changes are persistent, expected return behavior, or error handling for invalid paths.
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 with the main action forward-loaded and a concrete example. No filler or repetition, making it appropriately concise.
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 two-parameter setter with full schema coverage, the description and schema together give enough context to use the tool. It lacks guidance on alternatives and expected return behavior, but these are not critical for a basic set operation.
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 already provides detailed descriptions and examples for both parameters ('layerId' and 'attributes'). The description adds the dot-notation concept but largely echoes the schema, providing minimal additional meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets one or more attributes on a Cavalry layer, a specific verb+resource. It distinguishes from siblings like get_attribute by focusing on setting, and provides dot-notation path examples that clarify the 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?
No explicit guidance is given about when to use this tool versus alternatives like keyframe or set_generator. The purpose is clear, but usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation is a read ('Get a list') and reveals the output fields ('IDs and types'), but does not disclose prerequisites (e.g., whether a scene must be open), error behavior, or any side effects. This is adequate for a simple list operation but lacks explicit safety assertions.
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?
One sentence, front-loaded with the verb and resource, and no filler words. It conveys exactly what is needed without redundancy.
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 description explains the return value ('IDs and types') and covers the core purpose. It does not mention potential failure conditions or assumptions about the 'current scene', but for a simple read-only list tool with zero parameters, this is reasonably complete. The lack of an output schema is compensated by the explicit mention of returned fields.
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 effectively 100% (empty schema). The description adds no parameter-specific details, but none are needed. With no params to document, this dimension is well-handled by the schema, and the description doesn't obscure anything.
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 'Get a list of all layers in the current Cavalry scene' and specifies the return content ('with their IDs and types'). It distinguishes itself from siblings like cavalry_get_selected_layers and cavalry_get_composition_info by explicitly covering all layers.
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: you'd call this when you need all layers and their IDs/types. However, it does not provide explicit when-to-use guidance or contrast with alternatives such as cavalry_get_selected_layers. The context is clear from the sibling names, but no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It indicates a non-destructive status check ('Check if...'), which is useful, but it does not disclose what the tool returns on success or failure, nor any side effects or prerequisites like needing a prior connection. The behavior is described at a basic level but lacks detail.
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 main verb and resource. It contains no unnecessary words or repetition, making it optimally concise for the tool's simple purpose.
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 tool's simplicity (no parameters, no output schema), the description adequately covers the core behavior. However, it could be more complete by explaining the expected result (e.g., boolean or error behavior) and any dependencies on other tools like cavalry_connect. Still, for a health check, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description adds all necessary semantic context for parameters. No parameter explanation is needed, and the baseline of 4 applies because there are no parameters to document.
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 specific purpose: checking if Cavalry is running and the Stallion bridge is reachable. This distinct health-check function is clearly differentiated from sibling tools like cavalry_run_script or cavalry_create_layer, which perform other actions.
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 as a preliminary connectivity check before interacting with Cavalry, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. The context is clear enough to infer intent, but no explicit guidance or exclusions 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 provided, the description carries the full transparency burden. It implies a mutation operation (set) and provides an example, but does not disclose side effects, success/failure behavior, or layer compatibility requirements beyond the Basic Shape example.
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, with the main action in the first sentence and a clarifying example/secondary hint in the second. No redundant information.
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 tool, the description provides the action, an example, and a discovery method, which is adequate, though it lacks explicit return-value or error handling 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?
The input schema already describes both layerId and generatorId with examples, and the description's example of 'ellipse or rectangle' mirrors the schema's examples without adding significant new 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 uses the specific verb 'Set' with resource 'a generator on a layer' and provides an example with Basic Shape, clearly distinguishing it from other cavalry tools like cavalry_set_attribute.
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?
It gives contextual guidance by directing the user to api.getGenerators(layerId) to discover available generators, implying this tool is for setting one of those. However, it does not explicitly contrast with alternative tools such as set_attribute.
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 burden. It discloses 'arbitrary JavaScript' and 'most flexible', indicating broad, potentially far-reaching behavior. It goes beyond a generic 'run script' statement by naming namespaces, but it does not mention side effects, permissions, or error/return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: statement of action/resource, namespace guidance, and explicit fallback usage. No fluff, well front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a powerful arbitrary-code tool, but the description omits what the script returns, how errors are surfaced, or whether the script can mutate the scene. With no output schema, the description should clarify these behavioral outcomes, making the current description incomplete for safe and correct invocation.
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 coverage is 100% with 'JavaScript code to execute in Cavalry', so baseline is 3. The description adds value by naming the available namespaces, which clarifies what the code parameter can reference, going beyond the schema's minimal description.
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 'Execute arbitrary JavaScript in Cavalry's JavaScript Editor' — a specific verb and resource. It clearly differentiates itself from siblings by calling itself 'the most flexible tool' and a fallback for when no specialized tool fits.
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 explicitly instructs 'use it when no specialized tool fits', giving a clear decision rule. It also provides usage guidance by naming the relevant namespaces ('api, cavalry, and ui'), which helps the agent utilize the tool correctly.
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:

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

Score Badge

Copy to your README.md:

[![Cavalry-mcp MCP server](https://glama.ai/mcp/servers/kacperchlebowicz/Cavalry-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kacperchlebowicz/Cavalry-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/kacperchlebowicz/Cavalry-mcp'

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