AE-MCP

by davidcasan

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there are a few overlapping pairs (e.g., add_text_layer vs add_text_layer_advanced, set_keyframe vs set_keyframe_advanced) that could cause confusion. Descriptions help differentiate, but the advanced variants are not strictly necessary.
Naming Consistency4/5
The majority of tools follow a consistent verb_noun pattern (e.g., list_compositions, add_solid_layer, set_keyframe). A few outliers like debug_dump_layer and organize_project_items break the pattern slightly, but overall the naming is predictable and readable.
Tool Count3/5
With 68 tools, the server is on the heavier side. While the domain is complex, there is some redundancy (e.g., advanced versions of tools, multiple template functions) that could be consolidated. The count is borderline for a well-scoped server.
Completeness3/5
The toolset covers most core After Effects operations (project, composition, layer, keyframe, expression, effects, markers, import/export). However, notable gaps include video export, composition settings modification (beyond basic), and mask/matte management. The surface is extensive but not fully complete.
Average 2.6/5 across 68 of 68 tools scored. Lowest: 1.3/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 status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 fails to mention what the tool does concretely (e.g., replaces existing expressions, requires a selected layer, side effects on keyframes) and provides zero behavioral context beyond the tautological name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but not effectively structured. It does not front-load critical information beyond the name, and the brevity comes at the cost of clarity. Under-specification is not conciseness.
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?
With 7 parameters, no output schema, no annotations, and a single vague sentence, the description is completely inadequate for the agent to understand invocation, required context, or expected results. It fails to provide any meaningful context for a tool that clearly operates within a complex composition/layer system.
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 only 14% (only the 'params' field has a description). The tool description adds no parameter explanations—it does not clarify compId, compName, layerName, layerIndex, or the enum values for template. With low coverage, the description should compensate but fails entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply a pre-built expression template' which is a verb+resource, but it is vague and does not differentiate from sibling tools like set_expression or apply_effect_template. It lacks specificity about what the template applies to or how it integrates with the composition/layer context, making it barely adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives such as set_expression, enable_expression, or apply_effect_template. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, and the description fails to disclose any behavioral traits such as whether this adds a 3D light source, how it interacts with existing layers, or any side effects. The agent has zero insight into the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words, but it is under-specifying rather than concise. It squanders the opportunity to pack meaningful info into a short statement, offering no value beyond the name.
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?
With 6 parameters, no output schema, no annotations, and no context about behavior or usage, this description is entirely insufficient for an agent to select or invoke the tool correctly. Critical details are missing.
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%, yet the description adds no meaning to any of the 6 parameters (name, type, color, compId, compName, intensity). The agent cannot infer correct values or constraints from this description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description restates the tool name as 'Add a light layer' without adding any distinguishing context. Among many sibling add_*_layer tools (solid, text, shape, camera, etc.), this provides no differentiation, making it a tautology.
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 light layer tool versus other layer types or when to avoid it. The description does not mention scenes requiring 3D lighting or prerequisites like a camera layer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as whether the tool is destructive, synchronous, or returns a result. It does not mention side effects, permissions, or error conditions. The description adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but conciseness is achieved at the expense of essential information. Every sentence should earn its place, but this single sentence is insufficient to guide the agent. The structure is under-specified and lacks clarity.
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 the tool has six parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain how to identify the target layer or effect, the meaning of indices, or the behavior when indices are invalid. The agent cannot use this tool reliably.
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 explanation of the six parameters. The agent cannot infer what 'compId', 'compName', 'newIndex', 'layerName', 'layerIndex', or 'effectIndex' represent or how they relate. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reorder effects on a layer' is minimally clear, essentially restating the tool name. It specifies the resource (effects on a layer) but does not elaborate on the scope or distinguish from related tools like 'modify_effect_properties' or 'list_effects'. The purpose is understood but not enriched.
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 such as 'modify_effect_properties' or 'apply_effect'. The description lacks any context about prerequisites, required order of operations, or when not to use it. The agent has no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. There is no mention of side effects (e.g., replacing existing expressions), validation of the expression, permissions required, or whether the operation is reversible. The agent receives no 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but insufficiently informative. Under-specification for a tool with six parameters and no annotations means it does not 'earn its place' by providing necessary detail. Better to expand with structured guidance.
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 the tool's complexity (6 parameters, 2 required, no output schema, no annotations), the description is severely incomplete. It omits essential context about what constitutes a valid 'property', how to identify it, the role of composition and layer identifiers, and the expected behavior of setting an expression.
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 coverage is only 17% (only 'expression' has a description: 'JavaScript expression'). The tool description does not elaborate on any parameter's meaning or usage. Parameters like 'compId', 'compName', 'layerName', 'layerIndex', and 'property' remain unexplained, leaving the agent to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set an expression on a property' clearly states the verb and resource, but lacks specificity about which property (e.g., layer property, composition property) or context. It distinguishes from siblings like 'get_expression' and 'remove_expression', but remains vague enough to cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'apply_expression_template', 'add_expression_control', or 'enable_expression'. There is no mention of prerequisites, conditions, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'copy', giving no behavioral details. It does not disclose whether target property gets overwritten or appended, whether source must have keyframes, or any side effects. The description carries the full burden and fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which could be concise if it packed information, but it lacks essential details. For a tool with 9 parameters and no schema descriptions, this is under-specification, not conciseness.
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?
No output schema, no annotations, and a single sentence cannot adequately describe a complex operation with 9 parameters. Given the sibling tools for keyframe manipulation, this description fails to provide enough context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds zero meaning to any of the 9 parameters. Terms like sourceProperty, targetProperty, compId, layer identifiers are left undefined. The description does not help the agent understand parameter roles.
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 'copy keyframes' from one property to another. However, the term 'property' is ambiguous and does not differentiate from sibling tools like set_keyframe or get_keyframes, which also operate on properties. The verb+resource is specific, but lacks scope details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives (e.g., offset_keyframes, duplicate keyframes manually). No prerequisites, when-not-to-use, or context 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?
With no annotations present, the description bears full responsibility for disclosing behavioral traits. It does not state whether modifications are applied in place, if there are side effects on other layers, whether undo is supported, or any permission or state requirements. The single sentence provides no behavioral insight beyond the obvious verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is under-specified to the point of being unhelpful. 'Modify layer properties' could be considered tautological given the tool name. It does not earn its place because it adds no value over the name itself. A good concise description would pack useful constraints or examples.
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 20 parameters (including nested objects), no output schema, and no annotations, the description is vastly insufficient. An agent cannot determine what properties are modifiable, what the return type is, or how the parameters interact. Essential context like whether modifications are batched or immediate is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 20 parameters with 0% description coverage, and the tool description adds no information about any parameter. Parameters like 'compId', 'blendMode', 'position' (a nested object) remain unexplained. The agent has no hints about data types beyond the schema, relationships between parameters, or typical values. This is a critical gap for a tool with many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Modify layer properties' clearly identifies the verb ('modify') and resource ('layer properties'), but fails to distinguish this tool from numerous siblings like 'modify_composition' or 'modify_effect_properties'. The scope is vague; it doesn't specify which layer properties or the context (e.g., in a composition). Given the broad set of layer-related tools, this generic description does not help an agent differentiate intent.
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 'get_layer_info' (to read), 'set_keyframe' (to animate properties), or 'delete_layer' (to remove). There is no mention of prerequisites, typical workflows, or situations where other tools would be more appropriate. This leaves an agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It states the action ('remove expression') but does not reveal what happens if the property has no expression, whether the operation is reversible, if it requires specific permissions, or any side effects. The description is too sparse to adequately inform an agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short at 4 words, which is concise but sacrifices necessary detail. It is front-loaded and to the point, but fails to include critical information about parameters, usage context, or behavioral details. Every sentence should earn its place; here, the single sentence is too terse to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (including identifiers like compId and compName) and no output schema, the description is insufficient. It does not explain how to identify the target property, what constitutes a valid property, or the return value or confirmation of success. The description leaves major gaps for an agent to operate 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%, meaning none of the 5 parameters are documented in the schema. The description adds no information about any parameter, leaving the agent to infer the roles of 'compId', 'compName', 'property', 'layerName', and 'layerIndex' from their names alone. This is severely inadequate for a tool with 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove expression from a property' uses a specific verb and resource, indicating it removes an expression from a property. However, it does not distinguish itself from the sibling tool 'set_expression' or 'enable_expression', and fails to clarify what 'property' refers to or what happens when no expression exists. This vagueness limits its usefulness for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'set_expression' (to modify) or 'enable_expression' (to toggle). The description implies it should be used to clear an expression, but provides no context on prerequisites, such as whether an expression must already exist, or how it differs from modifying or disabling an expression. This lack of explicit guidance reduces clarity for selecting the correct 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 must disclose behavioral traits like whether adding a camera layer is destructive, requires specific permissions, or has side effects. The description says nothing about these aspects, leaving the agent uninformed about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at only four words, which is efficient but under-specified. It front-loads the basic function but lacks essential details, making it incomplete rather than appropriately concise.
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 has 5 parameters (0 required, 0% description coverage) and no output schema, the description is insufficient. It fails to explain return values, parameter usage, or context for camera layer addition, leaving significant gaps for an AI agent.
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 should compensate by explaining parameter meaning and relationships. The description provides no parameter information; for example, it does not clarify how 'type' enum values differ or how 'zoom' affects the layer, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a camera layer' provides a generic verb and resource but lacks specificity. It does not distinguish this tool from other layer-adding tools like add_solid_layer, add_text_layer, etc., leaving ambiguity about what a camera layer is and how it differs.
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 a camera layer is appropriate compared to a light or text layer. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. The description only states the action and result, omitting critical details such as whether the tool creates a new composition or layer, what 'animated text' entails (e.g., built-in preset animation), side effects on the project, performance implications, or required permissions. This is a severe gap for a tool with 13 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise in length, but it is severely under-specified. It does not earn its place because it fails to convey essential information about the tool's behavior, parameters, or usage. Effective conciseness requires sufficient detail, not just 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 the tool's complexity (13 parameters, 3 required, nested objects, no output schema), the description is completely inadequate. It does not explain what the tool returns, how it modifies the project, the relationship between parameters (e.g., 'style' and 'position'), or the meaning of 'animated text'. An agent cannot reliably invoke this tool based solely on the provided description.
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 only 31% (4 of 13 parameters have descriptions), so the description must compensate for the missing parameter documentation. However, the description adds no information about any parameter, leaving the agent to infer meanings from parameter names alone (e.g., 'style', 'animateIn', 'textColor' as an object). It fails to explain the enum options, optionality, or relationships between parameters.
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 verb 'Create' and the resource 'a lower third graphic with animated text', which is specific enough to distinguish from most sibling tools like 'create_composition' or 'add_text_layer'. However, it does not differentiate from closely related tools like 'create_title_card' or 'create_text_animator', which could also produce animated text graphics. A more precise distinction would be beneficial.
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, context (e.g., must have a composition open), or when not to use it. Without any usage guidelines, the agent lacks decision support for selecting this tool over similar creation tools listed as siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. The phrase 'Create a transition effect layer' is too vague to convey any side effects, auth requirements, or constraints (e.g., does it require a specific composition? Does it affect existing layers?). The description fails to provide essential 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It does not earn its place because it provides minimal utility. A helpful description should include key behavioral details, not just a restatement of the tool name.
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 the tool's complexity (6 parameters, nested objects, no output schema, no annotations), the description is grossly incomplete. It lacks information about return values, required parameters, dependencies, or any operational context. This is insufficient for an agent to correctly 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 any parameters. The input schema includes 6 parameters (type, color, compId, easing, compName, duration) with enums and nested objects, but the description adds no meaning beyond the schema. The agent receives no help in understanding parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a transition effect layer' clearly states the action (create) and resource (transition effect layer), but it is not specific enough to differentiate this tool from other layer-creation tools like add_solid_layer or add_text_layer. It implies a distinct type of layer but does not explain what makes a transition effect layer unique.
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_solid_layer or add_text_layer. There is no mention of prerequisites, context, or scenarios where a transition effect layer is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior, but it fails to mention that this tool likely performs a destructive operation (permanently removing a marker). It does not describe what happens to related data, whether confirmation is needed, or any side effects on other markers or the timeline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at three words, which could be considered concise, but it is under-specified to the point of being unhelpful. It does not earn its place because it fails to convey essential information. A description this minimal would only be acceptable if the tool name and schema were fully self-explanatory, which they are not.
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 (5 parameters, no output schema, and many sibling tools), the description is severely incomplete. It omits crucial context such as whether the marker is from a composition or layer, how to resolve conflicts (e.g., if multiple markers exist), and the return behavior (e.g., success message, void).
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%, meaning the description must explain parameters. However, it lists no parameter details. The schema has 5 parameters ('compId', 'compName', 'layerName', 'layerIndex', 'markerIndex') with only 'markerIndex' required. The description adds zero meaning beyond the raw schema, leaving agents to guess which context (layer vs. composition) and how to identify the target.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a marker' is vague and does not specify what type of marker (e.g., composition marker, layer marker) or from which context it is deleted. It lacks a specific verb-resource pairing that distinguishes it from sibling tools like 'add_composition_marker', 'add_layer_marker', or 'get_markers'.
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 such as 'get_markers' to list markers before deletion, or the difference between composition and layer markers. There is no mention of prerequisites (e.g., having the composition open) 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 must disclose behavior such as whether the tool destroys existing folder structure, requires specific permissions, or modifies the project irreversibly. The description offers none of this, stating only a vague purpose. For a tool that likely mutates the project, this is insufficient transparency.
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 concise, but it omits critical details. The sentence is front-loaded and easy to scan, but it does not earn its place since it fails to inform the agent adequately.
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 has 2 parameters, no output schema, and no annotations, the description should compensate by explaining how structure and customFolders work together, what the result looks like, and whether the operation is reversible. The current description leaves all these gaps unfilled.
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%, meaning the parameter names and enums carry the entire burden. The `structure` parameter has an enum but no description explaining what 'type', 'usage', or 'custom' mean. The `customFolders` parameter has no description clarifying whether these are new folders or must exist. The description adds no meaning beyond what the schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Organize project items into folders', which states a verb and a resource, but it is vague. 'Project items' could refer to layers, compositions, or footage, and 'organize' does not specify whether items are moved, copied, or rearranged. Among siblings like `import_folder` and `reduce_project`, this tool's purpose is not clearly distinguished.
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 `import_folder` (which also deals with folders) or `modify_composition`. No context about prerequisites, such as whether the project must be open or items must be selected, is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It fails to mention any side effects, error conditions (e.g., 'composition must exist'), or what happens if parameters are omitted. The single sentence 'Add a shape layer to a composition' gives no behavioral insight beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but insufficient for a tool with 12 parameters and no annotations. Important information is omitted including parameter relationships, default behaviors, and return type. The brevity sacrifices completeness for conciseness.
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 the complexity of the tool (12 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It fails to address prerequisites (e.g., needing a composition), error states, or what happens when the layer is added (return value, layer index, etc.). The user or agent would have to infer critical context from the schema alone.
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 58%, with 7 of 12 parameters having descriptions. The description adds no parameter-level information beyond what the schema already provides. It does not explain relationships between parameters (e.g., innerRadius only applies to star) or clarify ambiguous fields like 'points' or 'position'. The description fails to compensate for the uncovered parameters.
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 ('add') and the resource ('shape layer') to a composition. It distinguishes from sibling tools like add_solid_layer or add_text_layer by specifying 'shape layer'. However, it could be more specific about the shape type possibilities (e.g., rectangle, ellipse) which are in the parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., add_solid_layer, add_text_layer). There is no mention of prerequisites, context, or when a shape layer is appropriate. The description is purely functional without any usage direction.
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 describes the action as 'apply' but does not explain whether it adds, replaces, or modifies effects on a layer, whether it is destructive, or what side effects occur. The one-sentence description is insufficient for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is brief (one sentence), it is under-specified. Conciseness should balance brevity with informativeness; here, essential information is missing, making it too short to be helpful.
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 7 parameters, no output schema, and numerous sibling tools, the description does not cover expected return values, required context (e.g., existing composition/layer), or how the template interacts with layer effects. The tool is not adequately described 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 29% (just intensity and customParams have descriptions). The description adds no parameter explanations beyond the schema. Critical parameters like compId, compName, layerName, layerIndex, and template are left undocumented. The description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply a pre-configured effect template' which specifies the verb and resource. However, it does not differentiate from sibling tools like 'apply_effect' which also applies effects, nor does it clarify what distinguishes a 'template' from a direct effect. The purpose is adequately clear but lacks specificity.
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. alternative effect tools (e.g., apply_effect, modify_effect_properties). There are no prerequisites or context requirements mentioned, leaving the agent to guess the appropriate scenario for invocation.
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 exist, so the description must disclose behavioral traits. It only states the basic action. It does not explain whether the copy replaces or appends effects on the target layer, whether source effects remain, if the operation is reversible, or any permission requirements. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 7-word sentence, which is overly terse. While conciseness is valued, this level of brevity omits critical details needed to use the tool correctly. It is under-specified rather than efficiently informative.
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 the tool's complexity (7 parameters, no annotations, no output schema), the description is grossly incomplete. It fails to explain the effect of 'effectIndices' (e.g., all effects vs. selected), how source and target are identified (name vs. index priority), error handling, or what happens on success. The description provides almost no contextual value.
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 0% description coverage for 7 parameters. The description adds no information about how to use the parameters, which are required (none are marked required), the role of 'effectIndices', or the difference between name and index identifiers. The description does not 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 'Copy effects from one layer to another' clearly states the action (copy) and the resource (effects) with a clear source and target. It distinguishes this tool from siblings like 'apply_effect' (adds new effects) and 'remove_effect' (deletes effects). However, it does not specify whether it copies all effects or a subset, and the schema's 'effectIndices' parameter suggests selectable copying, which is not mentioned.
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, when not to use it, or contrast with sibling tools like 'reorder_effects' or 'modify_effect_properties'. The user/agent must infer usage from context, which is insufficient for a tool with 7 parameters.
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 exist, so the description carries the full burden. It only states the action without disclosing error conditions (e.g., what happens if no expression is present), side effects, or whether the operation is reversible. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very short, it is under-specified for a tool with 6 parameters. Conciseness is not achieved when essential information is omitted; every sentence should earn its place, but this single sentence provides minimal utility.
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 the tool has 6 parameters (2 required) and no output schema, the description fails to clarify which composition/layer identification method to use, what happens after toggling, or how the result is communicated. The presence of many sibling tools makes this omission more harmful.
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%, meaning the description adds no value beyond the parameter names. It does not explain the roles of compId vs compName, layerName vs layerIndex, or which identifiers are required. The 'property' and 'enabled' parameters are not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair ('enable or disable an expression'), which is specific. However, it does not differentiate from siblings like set_expression (which sets the expression code) or remove_expression (which removes it). The distinction that this tool toggles the active state is implicit but not elaborated.
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. For example, it does not mention that an expression must already exist for this tool to have an effect, nor does it suggest using set_expression first. The single sentence lacks any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits, but it merely states the action. It does not mention requirements (e.g., composition must exist), behavior when both 'compId' and 'compName' are provided or omitted, or any side effects. The return format and error handling are also absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is extremely brief but lacks substance. It is front-loaded but does not include enough information to earn its place; the brevity comes at the cost of completeness. A tool description should be concise yet informative—this is under-specified.
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 the tool has 2 optional parameters with no schema descriptions and no output schema, the description should provide context on usage, identification, and return behavior. It does none of these, leaving the agent to guess how to invoke the tool correctly and interpret results.
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%, putting the burden on the free-text description, yet the description does not mention the parameters 'compId' or 'compName' at all. It fails to explain that these are alternative identifiers for the target composition, or how they interact (e.g., precedence, mutual exclusivity).
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 'List all layers in a composition' uses a clear verb ('List') and specific resource ('layers'), scoped to 'a composition'. This distinguishes it effectively from sibling tools like 'list_compositions' (which lists compositions) and 'get_layer_info' (which retrieves details of a single layer).
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. For example, it does not explain how it differs from 'get_layer_info' for a single layer or when to use composition identification via 'compId' vs 'compName'. The agent receives no contextual usage cues.
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 says 'Add an adjustment layer' without any mention of side effects, required context (like which composition gets the layer), permissions, or whether the operation is reversible. This leaves the agent largely in the dark about behavior beyond the obvious action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single four-word sentence. While this avoids verbosity, the brevity comes at the cost of valuable context. It is not that it wastes words, but it fails to justify its existence by providing more than what the tool name already conveys. A 3 is appropriate for the size being minimally adequate.
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 simplicity (adding a layer) and the existence of many similar sibling tools, the description should at least mention the target composition requirement or the typical use case. It does not. With no output schema, no annotations, and no parameter guidance, the description is incomplete and likely insufficient for correct invocation without additional context.
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 only 33% (only the 'name' parameter has a description). The tool description adds no parameter information whatsoever. It does not clarify the roles of 'compId' and 'compName', nor how they relate to the target composition. With such low coverage and no compensatory text, the agent cannot infer parameter semantics from the description.
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 verb 'add' and the resource 'adjustment layer', so the agent understands the basic action. However, among many sibling tools like add_solid_layer or add_text_layer, it does not explain what distinguishes an adjustment layer, missing a chance to differentiate.
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 information is provided about when to use this tool versus any of the many other add_*_layer tools. There is no mention of prerequisites (e.g., a composition must exist), nor any alternative suggestions. The agent must rely solely on the tool name for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the basic action without mentioning prerequisites (footage must exist in project), effects on composition, what happens with conflicting param combinations, or whether the operation is reversible. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is a single sentence and free of fluff, it is under-specified to the point of being unhelpful for a tool with 5 parameters and 0 required. True conciseness balances brevity with completeness; here the brevity sacrifices essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, plus a moderate number of parameters and many sibling tools, the description is far from complete. It fails to explain valid parameter combinations, how the layer is positioned, or what constitutes a successful invocation. An agent would struggle to use this tool correctly without external documentation.
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 5 parameters with only 40% description coverage. The tool description adds zero information about how parameters like compId, compName, or startTime are used. It does not clarify whether compId or compName identifies the target composition, nor does it explain the role of startTime. The minimal schema descriptions ('Project item ID', 'Project item name') are not supplemented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Add a footage item as a layer') that clearly states the action. However, it does not differentiate this tool from sibling tools like add_solid_layer or add_text_layer, as it omits that this is specifically for adding a layer using an existing footage item from the project library.
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. With over 40 sibling tools for adding layers (e.g., add_solid_layer, add_text_layer) and related tools like import_footage, the agent receives no help in choosing the correct tool for a footage-based layer addition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Add a marker' without disclosing any behavioral traits such as whether it overwrites existing markers, permission requirements, side effects, or return value. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is too short for a tool with 9 parameters. It lacks front-loading of key details; conciseness is acceptable but not appropriately sized for the complexity.
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 the tool complexity (9 params, no output schema, no annotations), the description is severely incomplete. It omits what a marker is, how optional parameters interact, and expected return behavior.
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 coverage is only 11% (only 'time' has a description). The description adds no parameter explanations or context for the 8 undocumented parameters, failing to 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 clearly states the verb 'Add' and the resource 'marker to a composition', distinguishing it from layer markers (sibling 'add_layer_marker'). However, it doesn't specify the marker type (timeline vs cue point), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like add_layer_marker or delete_marker. The description provides no context for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It only states the action but omits critical details: side effects (e.g., does it modify the layer's properties?), required permissions, state changes, or whether the layer must already have an expression. The agent cannot infer behavioral traits from this minimal text.
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 sentence with no fluff, which is concise. However, it is too minimal to be effective; it lacks structure (e.g., no framing of when or how to use) and does not earn its place by providing necessary context. It is acceptable but not optimally structured.
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 the tool's complexity (7 parameters, 0% schema coverage, no output schema, no annotations), the description is severely incomplete. It does not explain parameter meanings, return values, required preconditions, or how this tool fits into a workflow. The agent has insufficient information to use the tool 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?
The schema has 0% description coverage, meaning all 7 parameters are undocumented in the schema. The description adds no parameter explanations whatsoever. The agent must rely solely on parameter names and the enum for 'controlType', which is insufficient for correct invocation. The description fails to add any meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add an expression control effect to a layer' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'set_expression' (which sets an expression on a property) and 'apply_effect' (general effect application). However, it does not elaborate on what an expression control effect is, leaving some ambiguity about its exact purpose.
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 'apply_effect' or 'set_expression'. The description does not mention prerequisites, typical use cases, or scenarios where this tool should be avoided, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether adding a null layer is destructive, whether it modifies the composition, or if there are side effects like affecting layer ordering. The description is too minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that gets directly to the point, earning its place with no wasted words. It is appropriately concise.
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 simplicity (adding a layer) and lack of output schema, the description could be slightly more complete. It does not explain what a 'null object layer' is or its typical use, nor does it clarify relationships between 'compId' and 'compName'.
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 low at 33%—only 'name' has a description. The tool description adds no extra parameter context, such as what 'compId' or 'compName' refer to or how they determine the target composition, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Add') and the resource ('null object layer'), which provides a clear purpose. However, it does not differentiate this tool from siblings like 'add_solid_layer', 'add_text_layer', etc., which have similar structures.
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 lacks any guidance on when to use this tool versus alternatives. With many sibling layer-adding tools, the agent receives no context about null objects' specific use cases (e.g., for parenting or expressions) 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 should fully disclose behavioral traits. It only mentions 'advanced styling options' without specifying what behaviors are involved (e.g., whether it creates a new layer, what default values are used, or how nested objects like color and position are interpreted). The description leaves 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—one sentence. It is not verbose, but it lacks necessary detail. It earns a middle score because it is not bloated, but the brevity sacrifices usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters (including nested objects), no output schema, and no annotations, the description is insufficient. It does not explain what the tool returns, the meaning of 'advanced' styling options, or the relationship to other layer tools. The description is incomplete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 20%. The description adds no parameter-level information beyond what the schema already provides. With 15 parameters including complex nested objects (color, position), the description fails to explain their structure or role, leaving agents to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add a text layer with advanced styling options', which is a clear verb+resource pair. However, it does not differentiate from its sibling 'add_text_layer', leaving ambiguity about what 'advanced' means exactly. This is a minimum viable description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus the simpler 'add_text_layer' sibling, nor does it mention any prerequisites or context for using advanced styling options.
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 exist, so the description must fully disclose behavioral traits. The description is minimal ('Collect project files to a folder') and does not state whether this is a read-only operation, mutates the project, or requires specific permissions. It doesn't explain if files are copied or moved, if the target folder must exist, or what happens to existing files. For a tool that likely manipulates project state, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (5 words), which could be considered concise, but it lacks substance. It is front-loaded in a single sentence but does not earn its place because it communicates almost no helpful information beyond the tool name. It is under-specified rather than efficiently summarized, reducing its utility.
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 has 3 parameters (some undocumented), no annotations, and no output schema, the description is far from complete. It omits essential context like input constraints (e.g., does outputPath need to be absolute?), side effects on the project, and return value. The tool's complexity is moderate (parameter count 3) but the description is too sparse to guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 33% of parameters have schema descriptions (outputPath has one), and the description adds no additional meaning to any parameter. The two boolean parameters (includeFonts, includeFootage) are completely undocumented—the description does not hint at their purpose or effect. With low schema_description_coverage, the description should compensate but fails to do so, leaving the agent to guess what each boolean does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool collects project files to a folder, which clearly indicates the action and resource. However, it does not differentiate between collecting project files versus the many other file-related tools like import_folder, replace_footage, organize_project_items, or find_missing_footage. The verb 'collect' is somewhat vague—does it copy, move, export, or package files? There is no specificity about scope or behavior that distinguishes it from siblings.
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. With many sibling tools related to files (import_folder, replace_footage, organize_project_items), there is no mention of prerequisites (e.g., a project must be open), scope (e.g., all files or only selected), or when not to use it (e.g., use import_folder to bring in new files instead). This leaves the agent without enough context to decide correctly.
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 'Create an animated logo reveal', implying mutation/creation, but fails to explain what the result is (new layer, new composition, modification of existing?), side effects, authentication needs, or whether the operation is reversible. This is insufficient for an agent to understand the tool's impact.
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 that front-loads the purpose. However, for a tool with 7 parameters and no output schema, this brevity comes at the cost of essential detail. It is undersized; additional context on behavior and parameters would be warranted without being verbose.
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 has 7 parameters (including nested objects), no output schema, and performs a creation operation with likely side effects, the description is far from complete. It does not explain the overall workflow, return value, prerequisites, or how the 'logo reveal' is integrated into the project. Important context is missing for effective use.
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?
With schema description coverage at only 29% (2 of 7 parameters have descriptions in the schema), the description should add meaning but does not—it contains zero parameter information. The agent must guess the semantics of 'compId', 'compName', 'duration', 'backgroundColor', and the distinction between 'logoItemId' and 'logoItemName'. The description adds no value beyond the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an animated logo reveal' provides a clear verb (create) and resource (animated logo reveal), making the core purpose understandable. However, it does not differentiate this tool from sibling creation tools like 'create_title_card', 'create_lower_third', or 'create_transition', which also create animations but for different assets. A more specific purpose statement would improve 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?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives (e.g., 'create_title_card' for titles), what prerequisites are needed (e.g., an existing composition or project), or what constraints apply. This leaves the agent without guidance on tool selection.
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 burden. It does not disclose whether the tool modifies the layer in place, whether it is destructive, or if any permissions or state dependencies exist (e.g., requires a selected layer or active composition). The description is minimal and lacks 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is overly terse for a tool with 10 parameters and no annotations. It would benefit from additional context or breaking down key aspects.
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 complexity (10 parameters, 40% schema coverage, no annotations, no output schema), the description is incomplete. It does not explain what happens after adding an animator, return values, or side effects. Important context such as whether the animator is appended to existing ones or replaces them is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 40%, meaning more than half of the parameters (delay, duration, endValue, layerName, startTime, layerIndex, compId, compName) have no description in the schema. The tool description does not compensate; it only mentions 'text animator' without explaining any parameter meanings or usage. The baseline for low coverage is higher, but the description fails to add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a text animator to a text layer' clearly states the action (add) and the resource (text layer), but does not distinguish from similar sibling tools like 'set_keyframe' or 'apply_effect' that might also manipulate animations. It is specific enough but lacks differentiation.
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 say when to use this tool versus alternatives, nor does it mention prerequisites such as requiring a text layer to exist or that the animator is applied to an existing layer. There is no guidance on 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?
With no annotations available, the description carries the full burden of behavioral disclosure. It does not state whether the tool is destructive, what it modifies (e.g., existing compositions), or any side effects. The vague 'with animations' does not clarify what animations are applied or whether they are configurable.
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, front-loaded sentence with no fluff. However, it is so brief that it feels under-specified rather than efficiently concise—key details are omitted that could be stated without adding length.
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 10 parameters, 0% schema coverage, no annotations, and no output schema, the description is far from complete. It fails to explain what a title card is, how animations work, what the return value might be, or how parameters interact. A tool of this complexity requires substantially more documentation.
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%, yet the description provides no insight into any of the 10 parameters (e.g., what 'style' enum values mean, how 'color' or 'backgroundColor' are structured, what 'compId' or 'compName' refer to). The description adds no meaning beyond the raw parameter names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('title card'), with an added detail ('with animations') that hints at output characteristics. This clearly distinguishes it from sibling tools like create_lower_third or create_text_animator, which address different visual elements.
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 such as create_lower_third or create_text_animator. There is no indication of prerequisites, context requirements, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it deletes a layer but does not disclose consequences such as whether deletion is permanent, if it affects sibling layers, or if any undo is possible. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), which is concise but underspecified. It could include more critical information without becoming verbose. Conciseness is only positive when it does not sacrifice clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool deletes a layer with four parameters, no output schema, and no annotations, the description is incomplete. It does not explain how to identify the layer, what happens after deletion, or error conditions. Compare to well-described sibling tools; this falls short.
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 explain each parameter's role. The description mentions none of the four parameters (compId, compName, layerName, layerIndex), leaving their semantics entirely unclear. The tool requires at least one identifying parameter, but no guidance on which combination is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Delete a layer', which clearly indicates the tool deletes a layer. However, it lacks specifics about what kind of layer (e.g., in a composition) and does not distinguish it from sibling tools like delete_marker or delete_composition. It is functional but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as delete_composition or modify_layer. There is no mention of prerequisites, idempotency, or when deletion is irreversible. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description omits behavioral details such as what happens when no expression exists, whether errors occur if the property is invalid, or what the return value looks like. With zero annotations, the description should disclose more behavior, but it provides only a bare statement.
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 sentence, which is concise, but it sacrifices necessary detail. It could be structured to front-load the core action and then add context, but currently it is too minimal for practical use.
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 5 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain what is returned, how to uniquely identify a property, or any side effects. An agent could not reliably invoke this tool correctly based solely on this description.
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%, yet the description does not mention any parameters or their purposes. Five parameters exist (compId, compName, property, layerName, layerIndex) with no explanation of how they identify the target property. This is a critical gap that leaves the agent guessing required inputs.
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: 'Get the expression from a property.' It uses a specific verb (get) and resource (expression), and distinguishes from sibling tools like set_expression or remove_expression. However, it does not clarify what constitutes a 'property' in this domain, which is a minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_keyframes or debug_dump_layer. No context about prerequisites or exclusions is provided. The agent receives no information on how to decide between this and similar read 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description does not indicate whether this is a read-only operation, whether it requires specific authorization, whether it modifies state, or what response format to expect. For a tool that retrieves 'detailed information', the lack of behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it could be front-loaded with more critical context (like prerequisite or parameter guidance) without adding length. The brevity is acceptable but misses opportunities.
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 zero annotations, zero schema coverage, and no output schema, the description must provide comprehensive guidance. It does not explain the return value, what 'detailed information' includes, any prerequisite layer state, or how the four parameters interact. This is a rich tool ecosystem (many sibling tools) where clarity about what this tool provides vs alternatives is critical, and the description falls short.
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%, meaning none of the 4 parameters (compId, compName, layerName, layerIndex) have descriptions in the schema. The tool description does not explain the meaning of these parameters, their relationships (e.g., whether compId and compName are alternatives), or how to use them correctly. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get detailed information about a layer', which uses a clear verb ('get') and resource ('information about a layer'). However, it doesn't distinguish from siblings like list_layers, get_comp_report, or debug_dump_layer. The purpose is clear but lacks specificity about what 'detailed information' includes.
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 instead of alternatives like list_layers, get_composition_info, or debug_dump_layer. The description provides no context about prerequisites (e.g., needing a composition with layers), exclusions, or expected scenarios. This leaves the agent to guess when get_layer_info is appropriate.
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 state whether the modification is destructive, requires specific user permissions, or affects other properties. The description says 'modify ... an existing effect', but does not explain what happens to unspecified properties or whether the change is atomic. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the core action ('Modify properties'). However, it is too brief to be maximally useful, bordering on under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (including a required nested object), no output schema, and no annotations, the description is critically incomplete. It does not explain how to identify the target effect, the format of the properties object, or what the return value looks like. Sibling tools like 'apply_effect' may offer more context, but this description alone is insufficient.
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%, meaning no parameters have descriptive hints in the schema. The description does not compensate by explaining how to use the seven parameters (e.g., whether compId or layerName is preferred, or how properties structure works). Only the 'properties' parameter is required, but its nested object semantics are completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'modify' and resource 'effect properties', which is clear but does not specify which fields can be modified or distinguish this from sibling tools like 'apply_effect' or 'remove_effect'. The purpose is adequate but lacks specificity about scope or constraints.
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 'remove_effect' or 'reorder_effects'. There are no prerequisites mentioned for identifying an effect (e.g., needing comp context or effect index) and no exclusion criteria. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. 'Reverse keyframe order' essentially restates the name. It does not disclose whether the operation is destructive, what happens with incomplete keyframe sets, or any performance implications. Almost no behavioral context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only three words. While there is no wasted text, it is so short that it fails to provide adequate information. Conciseness should not sacrifice clarity.
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 the tool's complexity (5 parameters, 1 required, no output schema) and the minimal description, the coverage is severely lacking. No information about return values, side effects, or usage context is provided, making it nearly useless for an AI 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%, yet the description adds no parameter explanations. The required 'property' parameter is not described. None of the five parameters (compId, compName, layerName, layerIndex) are given any semantic meaning in the description.
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 'Reverse keyframe order' clearly states that the tool reverses the order of keyframes. It distinguishes from sibling tools like offset_keyframes and scale_keyframe_timing by the specific action. However, it lacks specificity about scope (e.g., which keyframes, on what property/layer).
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 copy_keyframes or offset_keyframes. The description does not mention prerequisites, exclusions, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It merely states the action without explaining side effects (e.g., whether it modifies existing ease or adds new data), required conditions (e.g., keyframe existence), or the role of parameters like inSpeed/outSpeed. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of missing critical details about parameters and behavior. It is not well-structured for a complex tool; every word should earn its place, but here brevity hinders utility.
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 the high parameter count (10), lack of output schema, no annotations, and numerous sibling tools, the description is grossly incomplete. It omits essential context about parameter semantics, behavioral traits, and usage scenarios, making it inadequate for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema only provides parameter names and types. The description adds no explanation for any of the 10 parameters (e.g., inSpeed, outInfluence). The agent cannot infer their meaning from the description alone.
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 ('Set temporal ease') and the target ('on a keyframe'), making the purpose specific. However, it does not explicitly distinguish from sibling tools like 'set_keyframe_advanced' or 'apply_easy_ease', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or scenarios where 'set_temporal_ease' is preferred over other keyframe manipulation 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 must disclose behavioral traits. 'Set the work area' implies a mutation (changing something), but the description does not reveal if it overwrites previous settings, requires an existing composition, or has side effects like resizing other components. The description is too vague to help the agent anticipate consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which makes it easy to read quickly. However, it sacrifices necessary detail for brevity, bordering on under-specification. It earns its place but could benefit from an extra sentence or two to cover usage and semantics without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, no output schema, many sibling tools), the description is incomplete. It does not explain what 'set the work area' means operationally, how the parameters relate to each other, or what the tool returns (if anything). With no output schema, at minimum the description should state the expected outcome or return value.
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 50%, with 'start' and 'duration' having descriptions. The description adds no additional meaning beyond these param descriptions; it does not even list them or explain how they interact. For the undocumented params (compId, compName), the description provides zero help, and the schema descriptions are minimal (just type names and units). The description could have clarified the role of compId vs compName.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'set' and resource 'work area of a composition,' which is clear enough to understand the basic action. However, it lacks specificity about what 'work area' means in context (e.g., does it set the composition's work area for rendering or editing? It does not distinguish from sibling tools like get_composition_info or modify_composition, which deal with composition settings.
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. With many composition-related siblings like modify_composition, get_composition_info, and list_compositions, the description does not clarify whether this tool is for setting the preview region, render range, or something else entirely, nor does it mention any prerequisites or common use cases.
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 must fully disclose behavioral traits. It only states the action without mentioning side effects, prerequisites (e.g., layer must exist), error handling for invalid effect names, or whether the effect is added or replaces existing ones.
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 sentence, making it brief and front-loaded. However, for a tool with six parameters and no annotations, this brevity sacrifices necessary detail, resulting in a mediocre balance between conciseness and informativeness.
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 the tool's complexity (6 parameters, nested object, no output schema, no annotations), the description is critically incomplete. It omits prerequisites, return values, error scenarios, and behavioral context, leaving the agent with insufficient information to use the tool reliably.
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 low at 33%; only 'effect' and 'properties' have descriptions. The description adds no additional meaning to parameters like 'compId' vs 'compName' or 'layerName' vs 'layerIndex', nor does it explain the structure of the 'properties' object, failing to compensate for the schema's lack.
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 'Apply an effect to a layer' uses a specific verb-target pair ('apply', 'effect', 'layer') making the basic action clear. However, it does not differentiate from the sibling tool 'apply_effect_template', which likely applies a preset effect, missing an opportunity to clarify uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description gives no indication of when to use this tool over alternatives like 'apply_effect_template' or 'modify_effect_properties', leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It fails to mention whether deletion is permanent, if it triggers cascading effects (e.g., removing layers or referenced footage), or if confirmation is needed. The simple phrase 'Delete a composition' is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), which is concise but under-informative for a delete operation. It lacks necessary structure like a purpose statement or usage hints, making it borderline too brief to be useful beyond the tool's name.
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 (deletion can have irreversible effects) and the absence of output schema or annotations, the description is notably incomplete. It does not explain return behavior (e.g., success confirmation), error scenarios, or side effects, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the input schema (compId and compName), and schema coverage is 100%, so the baseline is 3. The description adds no extra context about parameter relationships (e.g., whether both are needed or they are alternatives), but the schema already provides basic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Delete' and the resource 'composition', which clearly conveys the core action. However, it does not distinguish this tool from siblings like 'duplicate_composition' or 'modify_composition' that also act on compositions. It is minimally adequate but lacks specificity to help the agent differentiate.
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, such as whether deletion is reversible, if there are prerequisites (e.g., composition must exist), or what conflicts may arise. There is no context about when not to use it, leaving the agent to guess.
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 bears full responsibility for behavioral disclosure. It only says 'Add a marker', which implies a creation action, but does not clarify side effects (e.g., does it replace existing markers? Is it reversible? What happens if the time already has a marker?). The agent receives minimal transparency about behavior.
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, but it is overly terse and leaves critical gaps. While there is no wasted text, the structure fails to front-load essential details like parameter roles or usage context. Conciseness is not valuable if it sacrifices completeness.
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 7 parameters (1 required) and no output schema, the description provides almost no context. It does not explain return values, error states, or how the parameters interrelate. Compared to the many sibling tools, the agent cannot infer how to construct a valid call without external knowledge.
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%—none of the 7 parameters have descriptions in the schema. The tool description does not explain any parameter meaning, such as the format of 'time' (seconds? frames?), the difference between 'compId' and 'compName', or whether 'duration' is optional. The agent has no semantic clues beyond 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 'Add a marker to a layer' clearly states the action (add) and the resource (marker on a layer), distinguishing it from sibling tools like 'add_composition_marker' which targets composition-level markers. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'set_keyframe' or 'add_composition_marker'. There is no mention of prerequisites (e.g., a composition must be open, layer must exist) or contexts that favor this tool. The description entirely lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention whether the tool is read-only (no mutation), what happens if the composition is missing, or any performance or side effects. While 'Get' implies a safe read, the description omits explicit behavioral traits that help the agent assess cost or risk.
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, clean sentence that is front-loaded with the verb and resource. It wastes no words. However, it could easily incorporate more detail (like usage guidance or behavioral context) while remaining concise, especially since it is very short.
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 there is no output schema and the tool has a sibling with a similar purpose (get_comp_report), the description is incomplete. It does not clarify what detailed information is returned (e.g., properties, metadata) or how it differs from list_compositions or get_comp_report. For a straightforward retrieval tool, the description is minimally adequate but leaves significant ambiguity.
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%, so both parameters ('compId' and 'compName') are already documented with basic descriptions. The description adds no further meaning beyond what the schema provides, such as whether one parameter is preferred over the other or how they relate. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose as 'Get detailed information about a composition', which pairs a clear verb ('Get') with a specific resource ('composition information'). However, it fails to distinguish this tool from its sibling 'get_comp_report', which likely serves a similar role. The description would benefit from specifying how 'information' differs from a 'report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool over alternatives like get_comp_report or list_compositions. The description lacks any context for prerequisites (e.g., does the composition need to exist first?), when-not-to-use scenarios, or selection criteria among siblings. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to specify whether retrieving keyframes is a read-only operation, what happens if the property has no keyframes, or any side effects. It doesn't describe the response format or data structure returned.
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 concise, but the terseness leads to under-specification. It could be front-loaded with a clear verb and object, but lacks necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (5 parameters, many sibling tools, no output schema), the description is too sparse. It does not explain return values, error conditions, or how parameters relate to each other, making it incomplete for effective use.
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 mentions 'property' implicitly but does not explain the roles of compId, compName, layerName, layerIndex, or property. An agent would not know how to uniquely target a property without guidance on which combination of parameters to use.
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 retrieves keyframes from a property, which is a specific verb-resource combination. However, among siblings like set_keyframe, copy_keyframes, and offset_keyframes, the description could better differentiate itself by mentioning it's read-only versus the others that are write or manipulation operations.
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 on when to use this tool versus alternatives like get_expression or the many other keyframe-related tools. There is no mention of prerequisites (e.g., the property must exist and have keyframes) 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 full behavioral transparency burden. It fails to disclose whether import is destructive (does it overwrite existing items?), whether permissions are needed, or what the response indicates (e.g., success, ID of imported item). The word 'import' implies creation, but mutation/read behaviors are undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 5 words – appropriately sized for a simple tool. No extraneous detail. However, it could benefit from front-loaded key info (e.g., 'Imports a single footage file into the current project.') without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, no annotations, and a complex set of sibling tools (import_folder, add_av_layer), the description is insufficient. It does not explain boolean parameters, error states, or return values. A user/agent would need to infer behavior from parameter names alone.
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%, so the baseline is 3. The description adds no meaning beyond the schema; it merely restates 'import footage file'. Parameters like 'sequence' and 'forceAlphabetical' are unmentioned in the description, relying entirely on schema descriptions. This meets minimum adequacy but does not enhance understanding of parameter combination effects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Import footage file into the project' uses a clear verb ('import') and resource ('footage file', 'project'), which distinguishes it from sibling tools that deal with compositions, layers, effects, or project management. However, it does not clarify that it imports a single file at a time, which could be ambiguous given the presence of 'import_folder' and 'replace_footage' siblings.
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 'import_folder', 'replace_footage', or 'add_av_layer'. No context is provided about prerequisites (e.g., is the project already open?), required file formats, or what happens if the file path is invalid. The description implies use for importing a file but gives no conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description should fully disclose behavioral traits. It does not mention whether the tool overwrites existing expressions, requires certain layers to exist, or what side effects occur (e.g., if source or target property is missing). The description is too terse to convey critical behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence. While it does not waste words, it is under-specified for the complexity of the tool (9 parameters). A balanced description would provide a bit more detail without being verbose, so this is minimally acceptable but not optimal.
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 9 parameters (2 required), no output schema, and low schema coverage, the description is far from complete. It does not explain how layers are identified, what 'offset' means, or how compId differs from compName. The agent lacks enough context to use the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 9 parameters with only 11% description coverage (only 'offset' has a description). The description adds no explanation for parameters like compId, sourceLayerName, targetLayerIndex, etc. With low schema coverage, the description should compensate but fails to do so, leaving significant ambiguity.
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 'Link two properties with an expression' clearly specifies the action (linking) and the resource (properties) with a means (expression). It differentiates from sibling tools like set_expression, which sets an expression on a single property, and apply_expression_template, which applies a template. However, it does not fully clarify what 'linking' entails (e.g., creating a pickwhip reference or generating an expression on the target).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description lacks any indication of when to use this tool versus alternatives such as set_expression or enable_expression. There are no examples, prerequisites, or scenarios mentioned, leaving the agent without guidance on choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It warns that offset applies to 'all keyframes' but does not specify scope (comp-wide vs layer-specific), whether the offset is additive and can move keyframes into negative time or beyond the composition length, whether it preserves temporal easing, or whether it requires the property to already have keyframes. The description is too minimal for a tool that modifies data.
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 concise but at the expense of necessary detail. It front-loads the action and resource, but does not earn its place by adding any behavioral or usage information. It is missing important context that future sentences should provide.
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 6 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain which parameters are needed to target specific layers or compositions, what the offset range limits are, or what happens when keyframes cross the timeline boundaries. The tool modifies data, so the agent needs more safety and scope information.
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?
With only 17% schema description coverage, the description must compensate heavily. There are 6 parameters, but the description provides no additional meaning for any of them. The schema already describes 'offset' as 'Time offset in seconds', but other params like 'property', 'compId', 'layerIndex' have no description in either schema or tool description. The agent is left guessing how to specify which keyframes to offset.
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 tool name 'offset_keyframes' combined with the description 'Offset all keyframes in time' clearly conveys the action (offset) and the resource (all keyframes). This differentiates it from sibling tools like 'reverse_keyframes', 'copy_keyframes', or 'scale_keyframe_timing' that also manipulate keyframes but with different actions. However, it does not specify whether the offset applies to all keyframes in a single layer, a comp, or project-wide, which leaves minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives such as 'scale_keyframe_timing' or 'reverse_keyframes'. There is no mention of prerequisites, what properties support keyframe offset, or whether this works on selected layers only. An agent would not know when to choose this over other timeline manipulation 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 must fully disclose behavioral traits. It reveals that the tool removes unused items, implying a destructive or modifying action, but does not explain what is considered 'unused', whether the action is reversible, or what items are affected (e.g., footage, compositions, layers). This lack of detail leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, clear phrase. It front-loads the action and resource. However, it could be slightly expanded to include the context that it affects the specified composition or project, but the brevity is otherwise effective.
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 the tool's complexity (project cleanup with two parameters, no output schema), the description is severely incomplete. It does not specify what 'unused' means, which parameters are required, what happens after removal, or how to verify results. The lack of detail makes it insufficient for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the two parameters 'compId' and 'compName'. However, it provides no parameter-specific information, leaving the agent to guess their purpose (e.g., which project? which composition?). The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'unused items from project', indicating a cleanup/optimization action. It distinguishes well from sibling tools like 'delete_composition' or 'delete_layer' which delete specific items entirely, rather than removing unused ones. However, it does not specify what qualifies as 'unused' or the scope of removal, which slightly limits its specificity.
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 such as 'delete_composition', 'organize_project_items', or 'collect_files'. The description does not mention prerequisites, side effects, or typical scenarios, leaving the agent without context to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the removal action but does not mention failure behavior (e.g., if effect is not found), side effects, or whether the operation is reversible. The agent has no insight into what happens beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is too terse given the tool's complexity (six parameters, no schema descriptions). It could be restructured to front-load key usage details while remaining concise.
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?
The tool has 6 parameters, no output schema, no annotations, and 0% schema coverage. The description provides almost no context: it doesn't explain parameter relationships, success/failure behavior, or required combinations. This is severely incomplete for an 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?
The description adds no meaning beyond the schema for the six parameters. It does not explain how to identify the effect (name vs index), whether effectName and effectIndex are alternatives, or how compId/compName/layerName/layerIndex disambiguate. With 0% schema coverage, the description fails to compensate.
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 ('Remove') and the resource ('an effect from a layer'). It effectively distinguishes this tool from siblings like 'apply_effect', 'modify_effect_properties', and 'list_effects' by specifying removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention when not to use it, prerequisites (e.g., effect must exist), or the distinction between removing by name vs index, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It doesn't mention that this modifies a keyframe (likely an undoable action), any potential side effects, or whether it requires a valid layer/composition. The description is too sparse to convey deeper behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with minimal waste, but it is under-specified. It is concise but not structured to provide useful information beyond a headline. It earns points for brevity but loses for not using the space to add value.
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 (11 parameters, nested objects, multiple easing controls) and no annotations or output schema, the description is insufficient. It doesn't explain the relationship between easing types and ease objects, nor the required context (layer, composition). The description covers only the basic purpose, leaving 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 only 9%, meaning most of the 11 parameters are undocumented. The description adds no parameter details beyond 'easing options', but doesn't explain how easing parameters (inType, outType, inEase, outEase) interplay or the meaning of 'time' and 'value' beyond basic types. Since schema coverage is very low, the description should 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?
Description states 'Set a keyframe with easing options', clearly indicating the verb (set) and resource (keyframe) with a specific focus on easing. However, it doesn't explicitly differentiate from sibling 'set_keyframe' or other keyframe manipulation tools, but the 'advanced' and easing focus imply distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over 'set_keyframe' or 'apply_easy_ease'. Given many keyframe-related siblings, the lack of explicit alternatives or contexts makes it ambiguous. No mention of prerequisites like needing an existing layer or composition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It does not state whether the operation is reversible, if it modifies the property in-place, or if it affects only selected keyframes. The tool is a mutator, but no warnings about idempotency or side effects are given.
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 at 4 words. While it lacks detail, it is front-loaded and free of filler. It could be expanded slightly to include key parameter hints without losing efficiency.
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 7 parameters and no output schema, the description is insufficient. The tool has a moderately complex input schema (layer selection via name/index, optional keyframe index, enum type) but the description explains none of this. The agent lacks information to correctly invoke the tool without diving into the 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 only 14%, meaning most parameters lack descriptions in the schema itself. The main description adds no parameter details—e.g., what 'type' enum values mean, how compId vs compName interact, or how layerName vs layerIndex disambiguate. This forces agents to guess or default.
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 'Apply easy ease to keyframes' clearly states the action (apply) and the resource (easy ease to keyframes). It is specific enough to distinguish from many sibling tools like set_keyframe, set_temporal_ease, and offset_keyframes. However, it could be slightly more explicit about whether it operates on a single keyframe or all keyframes of a property.
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 like set_temporal_ease, scale_keyframe_timing, or set_keyframe_advanced. The description does not mention prerequisites (e.g., keyframes must already exist or the property must be animatable) or situations where this tool should be avoided.
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 action 'Create a new composition' without mentioning side effects, permissions, whether it replaces an existing composition, or what happens to the project timeline. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but conciseness comes at the cost of missing context. For a tool with 6 parameters and complex creation logic, more detail is warranted. It is not optimally front-loaded with all necessary guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a creation tool. It lacks information on return values (no output schema), default values for parameters, required project state, and any constraints. Given the complexity and no annotations, the description fails to provide a complete picture.
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 has 100% description coverage with clear parameter descriptions (e.g., 'Width in pixels', 'Duration in seconds'). The tool description adds no extra meaning beyond the schema, earning the baseline score of 3.
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 'Create a new composition' clearly states the verb (create) and resource (composition), distinguishing it from sibling tools like duplicate_composition or modify_composition. However, it lacks any specificity about what a composition is or what the creation entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., duplicate_composition) or mention any prerequisites like having an open project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits—no mention of whether this operation is read-only (likely, but not stated), whether it requires specific permissions or project state, or what happens if both 'compId' and 'compName' are provided (e.g., which takes precedence). Since annotations are entirely absent, the description fails to compensate for this lack of 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 very concise at eight words. However, this brevity comes at the cost of crucial detail—it is under-specified rather than efficiently informative. A four-parameter tool with no schema descriptions and no annotations requires more explanation to be minimally useful.
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 that the tool has no output schema, no annotations, and four unspecified parameters, the description is incomplete. It does not explain the return format (e.g., list of marker objects with time, label, comment), how to distinguish composition vs. layer markers, or error conditions (e.g., what happens if no composition is found). It provides the bare minimum to understand the action but not enough to use the tool effectively.
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%, meaning the schema provides no descriptions for the four parameters. The description only mentions 'from a composition or layer' but does not explain how 'compId', 'compName', 'layerName', and 'layerIndex' relate or when one is preferred over another. This leaves the agent with minimal semantic information beyond parameter types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and resource ('markers from a composition or layer'), which immediately conveys the tool's basic function. However, it does not distinguish itself from sibling tools like 'add_composition_marker', 'add_layer_marker', or 'delete_marker', nor does it specify the output format or scope (e.g., all markers vs. specific marker types).
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, such as when to use 'get_keyframes' instead or how to filter by composition vs. layer. There is no mention of prerequisites (e.g., requiring a composition to be open), which is critical for a tool that expects 'compId' or 'compName' as optional parameters.
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. 'List' implies a read-only operation, but it does not disclose whether the operation returns effect names only, includes disabled effects, or if any side effects occur. No additional context is added beyond the bare verb.
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 core action and object. Every word is necessary, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, zero annotations, and no output schema, the description is far too minimal. It does not explain how parameters interrelate, what the return format is, or how errors are handled. An agent cannot safely infer how to invoke this tool correctly without additional information.
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 explain the four parameters (compId, compName, layerName, layerIndex) at all. While 'on a layer' hints at layerName/layerIndex, the description fails to clarify how composition and layer identifiers work, which parameter combinations are valid, or whether any are required. The description adds no semantic value over the schema's raw types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all effects on a layer' uses a specific verb ('List'), identifies the resource ('effects'), and scopes it to a layer. This clearly distinguishes it from sibling tools like list_layers (which lists layers) and apply_effect (which adds effects).
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 vs alternatives. There is no mention of prerequisites, exclusions, or relationships to other effect-related tools like modify_effect_properties or remove_effect. The intended use case is only implied by the verb 'list'.
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 modification action but does not explain whether the tool mutates in place, returns a response, or requires specific permissions. It provides minimal insight beyond what the tool name implies.
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, but it is overly minimal. While brevity is valued, the lack of additional information (such as parameter relationships or return behavior) means the sentence does not earn its place by providing sufficient guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (0 required) and no output schema, the description should explain what the tool returns and how modifications apply. It does not address these. The absence of annotations further increases the need for a richer description, which is not provided.
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%, so each parameter already has a description. The tool description adds no additional context (e.g., mutual exclusivity of compId and compName, or default behavior when fields are omitted). Baseline 3 is appropriate since the schema does the heavy lifting.
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 'Modify an existing composition' clearly states a specific verb-resource action. It distinguishes from siblings like 'create_composition' or 'delete_composition' by targeting modification of an existing entity. However, it lacks details that would further clarify purpose, such as the scope of modifications allowed.
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. For example, it does not explain that a composition must exist before modification, nor does it contrast with 'duplicate_composition' for copying. The description is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the full burden is on the description to disclose side effects (e.g., whether it overrides existing keyframes at the same time) or operational constraints. Description merely restates the action with no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence, no unnecessary words. However, it is overly terse for a tool with 7 parameters and important constraints, which reduces utility.
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?
No output schema, 43% parameter coverage, no annotations. Description does not specify return behavior (e.g., success confirmation, errors), nor does it address the complex value types (number, array, object, string) beyond what the schema mentions. Incomplete for a 7-param animation tool.
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 covers 43% of parameters. The description repeats the schema's 'property' example but adds no extra meaning beyond it. Baseline of 3 is appropriate as schema partially documents time, value, and property, but the description fails to compensate for the other 57%.
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 verb 'Set' and the resource 'keyframe on a property', which is a specific animation action. It distinguishes from sibling tools like 'set_keyframe_advanced' and 'set_expression' but does not explain the exact difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. alternatives like 'set_keyframe_advanced'. The description implies basic keyframing but fails to mention prerequisites (e.g., which layer/property must exist) or when to prefer 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the action but does not mention side effects (e.g., whether it replaces existing layers, auto-selects, or requires certain permissions). There is no mention of what happens if required parameters are missing or how the color's RGB ranges are enforced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the core action. It is appropriately concise for a tool with a detailed schema covering the parameters.
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 complexity (8 parameters, nested color object, many sibling tools) and the lack of annotations and output schema, the description is minimally adequate but incomplete. It provides no usage examples, explains no return values, and gives no detail on how the tool interacts with the composition (e.g., adding at the top vs. bottom of the layer stack).
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 has 100% description coverage for 8 parameters, so the baseline is 3. The description of color adding context about 0-1 range and default behavior for width/height (defaults to comp width/height) is helpful but adds minimal extra beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a solid color layer to a composition. The verb 'add' plus the resource 'solid layer' and target 'composition' make the purpose unambiguous. While it distinguishes this from other layer-adding siblings, it doesn't elaborate on what makes a solid layer unique versus shape or text layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like add_shape_layer or add_text_layer. There's no mention of prerequisites (e.g., a composition must exist before adding a layer) or scenarios where a solid layer is preferred. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavior disclosure. It only states that a text layer is added, with no information on side effects (e.g., does it affect existing layers?), return values, error conditions, or prerequisites. The agent cannot determine whether this operation is safe, reversible, or requires specific authorization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, aligning well with conciseness expectations. However, for a tool with 9 parameters and nested objects, this brevity sacrifices informative value. A slightly expanded description (e.g., noting optional composition targeting) would improve structure without becoming verbose.
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 9 parameters including nested objects, no output schema, and no annotations. The description fails to address key contextual gaps: how the composition is identified, behavior when compId/compName are omitted, color format, or return details. This inadequacy makes it difficult for an agent to use the tool effectively without external knowledge.
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 78%, and the tool description adds no parameter-level context beyond what the schema already provides. For example, it does not explain the 'color' object structure, the meaning of 'justification' values, or how 'compId' vs. 'compName' target the composition. Baseline of 3 is appropriate as the description adds no value over schema, but does not contradict it.
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 'Add a text layer' and the target 'composition', which is specific and distinguishes it from sibling tools like 'add_solid_layer' or 'add_shape_layer'. However, it does not differentiate from the closely related 'add_text_layer_advanced' sibling, which could lead to ambiguity for the agent when choosing between basic and advanced text layer creation.
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, such as 'add_text_layer_advanced' or other layer-adding tools. There is no mention of preconditions (e.g., requires an active composition) or context for effective usage, leaving the agent without decision-support 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without explaining the consequences of closing (e.g., unsaved changes may be discarded if 'save' is false). The parameter schema partially addresses this by describing 'save', but the description itself omits critical safety information 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately concise for a simple action. While it could be expanded to include behavioral context without becoming verbose, its brevity is a strength in terms of readability.
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 that performs a potentially destructive action (closing a project), the description is incomplete. It does not explain what happens to unsaved work, whether the user is prompted, or what the tool's return value indicates. The parameter schema offers a hint, but the description itself fails to provide a complete picture of the tool's behavior and 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?
Schema description coverage is 100% (the 'save' parameter has a description: 'Save before closing'). The tool description adds no additional meaning beyond the schema. With full coverage, a baseline of 3 is appropriate; the description does not enhance or clarify parameter semantics further.
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 'Close the current project' clearly identifies the action (close) and the resource (project), and it distinguishes itself from sibling tools like create_project, open_project, and save_project. It is specific enough to convey the primary intent, though it could benefit from mentioning what 'close' entails (e.g., whether unsaved changes are lost).
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 save_project or get_project_info. No context is provided about prerequisites (e.g., having an open project) or when it is appropriate to close without saving. The description offers no exclusions or comparisons to sibling 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 present, so the description carries full burden for behavioral disclosure. It only says 'Create', which implies non-destructive action, but fails to mention side effects (e.g., whether the current project is closed, if auto-save occurs, or if it modifies the application state permanently). The description is insufficient for an agent to predict the tool's full 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 sentence of six words, front-loading the verb and resource. It contains no filler or redundant information. Every word earns its place for this straightforward action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, no output schema, no annotations), the description covers the basic action but leaves critical gaps: it does not explain what happens when 'name' is omitted, whether a file is created/saved, or how this interacts with the current application state. A more complete description would clarify these behavioral 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?
Input schema has 1 parameter ('name') with description 'Optional project name', providing 100% coverage. The tool description adds no additional meaning beyond what the schema already states. Baseline score of 3 applies because schema coverage is high and the description does not improve parameter understanding.
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?
Description clearly states the verb 'Create' and resource 'a new After Effects project'. It directly conveys the core action, distinguishing it from sibling tools that operate on compositions or layers. However, it does not explicitly differentiate itself from other creation tools like 'create_composition' or 'import_footage', leaving room for ambiguity about the scope of 'project'.
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 (e.g., open_project, save_project, import_footage). The tool name suggests it should be used to start a new project, but the description does not clarify prerequisites, typical workflow position, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the basic action but does not describe side effects: whether original layers are removed, whether the new composition is automatically added to the project, or if the original composition is altered. This leaves an agent unaware of mutation consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no redundant words. It is appropriately concise, though it could be slightly expanded to improve completeness without sacrificing brevity.
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 has 5 parameters (2 required) and no output schema, the minimal description is insufficient. It does not explain what the function returns (e.g., the new composition object), any prerequisites (e.g., layers must exist), or post-conditions. Agents would lack operational 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?
The description adds no parameter information beyond what the input schema already provides. With only 60% schema description coverage, two parameters (compId and compName) lack descriptions entirely, and the tool description does not clarify their purpose or usage. The description fails to compensate for these gaps.
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 'Precompose selected layers into a new composition', using a specific verb ('precompose') and resource ('layers into a new composition'). This distinctly differentiates it from sibling tools like add_layer, delete_layer, or modify_composition, which perform different operations.
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. For example, it does not mention that this operation creates a new composition from selected layers, while sibling tools like duplicate_composition or create_composition exist. No when-not-to-use or prerequisites are given.
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 provided, so the description carries full burden. It states 'replace' implying mutation, but does not disclose whether the replacement is destructive, whether it updates all composition references, or if the old file is deleted. Critical behavioral traits are missing.
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 with no fluff. However, it is under-specified; while front-loaded and direct, it could include essential details without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, low schema coverage, and no annotations, the description is insufficient. It does not explain return values, side effects on compositions, or whether the new file must exist. The agent lacks context to invoke the tool safely.
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 only 33% (only newPath has a schema description). The tool description adds no additional parameter meaning—it does not explain itemId or itemName. The agent is left to infer that itemId identifies the footage, but no confirmation is given.
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 resource 'footage item' with a new file, clearly indicating the action. It distinguishes from sibling tools like import_footage (import new) and find_missing_footage (locate missing).
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 on when to use this tool vs alternatives (e.g., import_footage). No mention of prerequisites, such as whether the footage item must already exist in the project or what happens to existing 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?
No annotations are provided, so the description must fully convey behavioral traits. It only states 'Save the current project', implying an overwrite of the existing file or a new save if unsaved, but does not disclose whether it shows a prompt, overwrites without warning, or what happens with invalid paths. Side effects like file modification are implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of four words: 'Save the current project'. It is maximally concise with no wasted words. Every part earns its place by conveying the essential action and target. For a simple save operation, this level of conciseness is appropriate.
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 simple tool signature (1 optional param, no output schema), the description lacks important details for complete usage. It does not explain the behavior difference when 'path' is provided vs. omitted, nor does it mention confirmation dialogs, overwrite warnings, or the tool's relationship to 'close_project'. The agent would need to infer or test behavior.
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% as the single parameter 'path' has a description. The tool description adds no meaning beyond what the schema already provides ('Optional path to save as'). While the overall description gives context, it does not enrich the parameter semantics with additional details like format, relative path handling, or overwrite rules.
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?
Description states 'Save the current project' which clearly identifies the action as saving an existing project. It is specific about the resource ('current project') and the operation ('save'). However, it does not differentiate from similar sibling tools like 'close_project' which may also involve saving, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as 'create_project' or 'close_project'. It does not explain under what circumstances to provide the optional 'path' parameter (save-as) versus omitting it (overwrite existing). There is no instruction on prerequisites like requiring an open project.
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 bears full responsibility for disclosing behavioral traits. It only states the high-level purpose ('scale keyframe timing'), but omits critical details: whether the operation is destructive, how anchorTime affects behavior, what happens to keyframe values vs positions, idempotency, or response format. This is insufficient for a tool with 7 parameters.
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 front-loads the action. It contains no fluff, earning a 4, but could expand slightly to improve other dimensions without becoming verbose.
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 7 parameters, 2 required, and no output schema. The description does not explain key aspects: what 'scaling' means in terms of keyframe time distribution, the role of anchorTime, or the requirement for a qualified property. For this complexity level, the description is under-specified and incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (2 of 7 parameters documented). The description adds minimal value: it refers to scaling as 'speed up or slow down', which maps to the 'scale' parameter, but fails to clarify the other 5 undocumented parameters (compId, compName, property, layerName, layerIndex). With low coverage, the description should compensate but does not.
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 'Scale keyframe timing (speed up or slow down)' uses a specific verb ('scale') and resource ('keyframe timing'), clearly indicating what the tool does. It also distinguishes this tool from sibling keyframe manipulation tools (e.g., offset_keyframes, reverse_keyframes) by focusing on timing scaling, which is a unique operation in the set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like offset_keyframes, reverse_keyframes, or set_keyframe. It does not specify the required context (e.g., existing keyframes on a property), prerequisites, or when scaling is inappropriate, leaving the agent without decision-making criteria.
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 'Get information' implying a read operation, but lacks details about side effects, permissions, or what the response contains. Critical behavioral traits are missing.
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 with no wasted words. However, its brevity comes at the cost of completeness; it is not optimally sized because it omits important details about the return value.
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 has no parameters and no output schema, the description should fully explain what information is returned. It fails to do so, leaving the agent to guess the nature of the output. For a simple tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage (trivially). Following the baseline rule for 0 params, the description adds no param information, which is acceptable. However, it could clarify what 'current project' means (e.g., active document in the application).
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 retrieves information about the current project, distinguishing it from composition-specific tools like get_composition_info. However, 'information' is vague; specifying what data is returned would elevate 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?
No guidance is given on when to use this tool versus alternatives such as get_composition_info or get_comp_report. There is no mention of prerequisites, context, 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the action ('find') but does not reveal whether this is a read-only operation, whether it modifies the project state, how results are returned, or what constitutes 'missing' footage. The description lacks critical 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 sentence, concise and front-loaded with the core purpose. However, it may be overly terse, sacrificing useful context for brevity. While no words are wasted, additional information could be included without compromising conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters or output schema, the description is the only source of contextual information. It fails to explain what the output looks like, how to interpret results, or any side effects. For a simple tool, this is insufficient for an agent to know how to use the result effectively.
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 has no parameters, so schema description coverage is 100% by default. The description does not add parameter semantics because there are none to describe. The baseline score of 3 is appropriate as the description neither adds nor detracts from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find all missing footage items in the project'. It uses a specific verb ('find') and resource ('missing footage items'), which distinguishes it from sibling tools like 'replace_footage' or 'import_footage'. The scope is well-defined and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, nor does it mention prerequisites or context. For example, it does not clarify whether the tool scans the entire project or only selected items, or what to do after finding missing footage. No exclusion criteria or alternative tool names are given.
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 states 'Import all files' but does not disclose what happens if the folder is empty, if files are unsupported, or whether this operation is destructive. No mention of error handling, side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of five words, which is extremely concise. However, for a tool with two parameters and no annotations, it may be too sparse to be fully helpful. It is not wasteful, but under-specification slightly reduces effectiveness.
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 complexity (two parameters, no output schema, no annotations, and many sibling tools including 'import_footage'), the description is incomplete. It does not specify whether folders are imported as collections or individually, what happens to existing project structure, or how errors are handled. The agent lacks sufficient context to use the tool reliably.
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%, so parameters are already documented. The description adds 'all files' which clarifies the scope but does not provide additional meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting and the description offers marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'import' and the resource 'all files from a folder'. It distinguishes from sibling tools like 'import_footage' which imports specific footage files, and other unrelated tools. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'import_footage' or 'replace_footage'. The description does not specify prerequisites, potential conflicts, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It correctly implies duplication is a mutation (creating a new composition from an existing one). However, it fails to disclose side effects like whether the source composition is modified, what is duplicated (entire structure, only root?), or error states (e.g., dup of non-existent comp). This is baseline adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief at 3 words. This is efficient but borderline under-specified. In a tool with three parameters and no annotation coverage, a single sentence is too terse to be helpful; yet it avoids unnecessary fluff. It is structured well for quick scanning.
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 complexity (3 parameters, no output schema, no annotations, many sibling operations like create/modify composition and delete/layer ops), the description is minimally complete: it states the primary action but omits context about prerequisites, behavior on failure, and side effects. For a faithful agent, more details would improve safe selection.
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%, so each parameter's purpose is stated in the schema (compId, newName, compName). The description only repeats 'duplicate' without adding semantic nuance like whether newName is optional, or whether compId must be an existing composition ID. It adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-resource pair: 'Duplicate a composition'. It expresses a single specific action, and though it does not explicitly differentiate from siblings like 'create_composition' or 'modify_composition', the duplication intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no context about prerequisites (e.g., the composition must exist), no hint about naming constraints, and no mention of when to prefer create_composition or modify_composition instead.
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. It only states 'Open an existing After Effects project' without mentioning side effects (e.g., closing current project, prompting to save), file lock behavior, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is appropriately short and front-loaded, earning its place.
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, no annotations), the description is functional but lacks critical context about state changes (e.g., closing current project) and error conditions. It is complete enough for a basic understanding but not for robust agent decision-making.
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 one parameter (path) already described in the schema. The description adds no additional meaning beyond the schema, such as accepted file formats, path conventions, or restrictions.
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 'Open an existing After Effects project' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_project, save_project, close_project, and import_footage.
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. It does not mention prerequisites (e.g., project must exist, not already open) or exclusions (e.g., cannot open while another project is open without saving).
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 bears full responsibility for behavioral disclosure. It states 'recursively dump' (indicating traversal) and names the output fields, but does not disclose side effects (is it read-only?), performance impact (deep recursion could be expensive), or output format (structured? raw text?). Basic behavior is clear but important safety and format details are missing.
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 single sentence efficiently communicates purpose, target, and content. It is front-loaded and avoids redundancy. However, it could incorporate parameter or usage guidance without becoming verbose; as is, it is concise but slightly under-informative.
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 has 5 required parameters (none required, but complex identification), no output schema, and no annotations, the description is too sparse. It does not clarify parameter usage or what the dumped output looks like, leaving significant gaps for an agent to correctly invoke and interpret results. The tool's diagnostic nature demands more 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?
With schema description coverage only 20% (only maxDepth has a description), the description must compensate for the other 4 parameters. However, it does not explain compId vs compName, layerName vs layerIndex, or how these identify the layer (priority, mutual exclusivity, etc.). The description adds no semantic value beyond the schema names, leaving the agent uncertain about parameter relationships.
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 ('dump') and resource ('layer's property tree') with clear inclusion list (names, match names, expressions, keyframe counts) and purpose ('diagnostics'). It strongly distinguishes this tool from siblings like get_layer_info or list_layers, as no other sibling offers recursive property dumping.
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 mentions 'for diagnostics' implying when to use, but lacks explicit guidance on when not to use or alternatives. For example, it could clarify that get_layer_info is preferred for basic layer info, or that this tool is heavy and should be used sparingly. With many sibling inspection tools, this omission is noticeable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While it accurately states that a frame is rendered and saved to disk returning a file path, it omits important behavioral traits such as potential overwriting of files, performance impact (e.g., rendering time), whether the operation is read-only, or permission requirements. These gaps leave the agent without critical context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences (22 words), front-loading the primary action and result. Every sentence contributes value, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately notes the return value (file path). However, given the tool has five optional parameters, the description does not clarify how to identify the composition (compId vs compName) or handle defaults. It is minimally complete for a simple render but could better guide the agent on parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all parameters with descriptions. The description adds no additional meaning to the parameters beyond what the schema provides. Baseline 3 is appropriate, as the description does not improve parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Render a single frame'), the resource ('a composition'), the output format ('PNG file on disk'), and the return value ('file path'). It distinguishes this tool from siblings, as no other tool in the list renders frames to disk for visual inspection.
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 use when the AI needs to 'inspect what the comp actually looks like,' which is a visual context. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_comp_report for text reports), and it provides no exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic operation without mentioning return format, pagination, sorting, or side effects. For a read operation, it would be valuable to note that it is non-destructive and what data is returned (e.g., composition names/IDs). The minimal disclosure leaves the agent uninformed about output structure or constraints.
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 zero wasted words. It conveys the core function efficiently and is easy to parse. Every word earns its place.
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 that there is no output schema and no annotations, the description is complete enough for a simple list operation. However, it omits useful details such as whether the result is an array, what fields are returned (e.g., composition ID, name), and any ordering. For a tool with many siblings, a slightly richer description would improve contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100% (trivially). With no parameters to document, the description adds no specific semantic value beyond what the schema provides. However, the baseline for zero-param tools is 4, as the description is clear about the operation. It does not need to explain parameters that don't exist.
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 'List all compositions in the project' uses a specific verb ('list') and resource ('compositions'), clearly distinguishing it from siblings like create_composition, delete_composition, and get_composition_info. The scope is explicit (all in the project), leaving no ambiguity about the tool's function.
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 on when to use this tool versus alternatives such as get_composition_info or duplicate_composition. The description implies basic listing functionality but does not clarify when a user would prefer this over other list tools (none exist) or how it relates to other composition operations. Usage is implied but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses default sampling behavior (markers or 5 uniform points) and lists the data types included. However, it does not mention any prerequisites, performance implications for large compositions, or whether the operation is read-only.
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 sentences, front-loaded with the core offering, zero filler. Every word contributes to understanding the tool's output and 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 complex tool with 4 optional parameters, no output schema, and no annotations, the description adequately covers what data is returned and default behavior. However, it lacks description of the output structure (e.g., how layers are organized) and does not mention error conditions or constraints.
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 baseline is 3. The description adds value by clarifying default behavior for 'sampleTimes' (markers by default) and 'textPreview' (120 max characters), which goes beyond the schema descriptions. It subtly ties the parameters to the tool's purpose.
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 returns a 'full composition report' with specific content (geometry, text data, fonts, expressions, keyframes, animated values). It distinguishes from siblings like 'get_composition_info' which likely provides metadata only, and 'list_layers' which is a simpler listing.
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 explicitly says 'Use it to verify the real state of a comp,' providing a clear usage context. However, it does not contrast with alternatives such as 'get_composition_info' or 'list_layers' for 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.

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:

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

Score Badge

Copy to your README.md:

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

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/davidcasan/MCP-AE2'

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