MCP Scroll Animation Analyzer

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation4/5
Each tool targets a distinct aspect of scroll animation analysis, from opening and interacting with the page to extracting code, monitoring elements, and exporting replicas. Some tools like extract_animation_code and deep_script_analysis have overlapping domains, but their descriptions clarify different purposes.
Naming Consistency4/5
Most tools follow a verb_noun pattern (open_page, get_scroll_triggers, generate_report), but a few deviations like scroll_and_record (two verbs) and deep_script_analysis (noun phrase) break the convention. This is mostly consistent with minor exceptions.
Tool Count4/5
With 16 tools, the server is slightly above the typical well-scoped range but each tool serves a clear purpose in the analysis workflow. No tools are redundant, though some could potentially be consolidated.
Completeness5/5
The toolset covers the full analysis lifecycle: page opening, interaction, scrolling, recording, extracting CSS/JS code, monitoring elements, tracing execution, generating reports, and exporting code. There are no obvious gaps or dead ends.
Average 3.2/5 across 16 of 16 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only says 'inject tracing,' which implies modification of the page without specifying side effects, reversibility, or expected output. It doesn't mention whether this alters runtime behavior or how it impacts the page after execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It prioritizes the main purpose and is front-loaded, though it could be slightly expanded to cover parameters or behavior 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?
Given the tool's complexity (nested parameter, no annotations, no output schema), the one-line description is insufficient. Users don't know what the returned data looks like, whether tracing changes the page, or how scrollRange interacts with the scroll event, leaving significant gaps for reliable 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?
The input schema defines a nested 'scrollRange' object with start and end, but the description provides no explanation of what these parameters do or how they affect tracing. Schema description coverage is 0%, and the description adds no value in clarifying parameter meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: injecting tracing to capture GSAP calls during scroll. It uses a specific verb phrase and names the target (GSAP calls) and context (during scroll). While it doesn't explicitly contrast with siblings, it 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?
No guidance is provided on when to use this tool versus alternatives like scroll_and_record or get_scroll_triggers. There are no prerequisites or use-case indicators, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It does not mention that this is likely a read-only analysis, any performance implications, or what happens with results. The phrase 'deep analysis' hints at thoroughness but lacks details about side effects or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It earns its place by conveying the main purpose, though it omits needed elaboration. This is concise but not necessarily well-structured for complex information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool that likely performs a comprehensive analysis. It does not explain return values, expected output format, or how it relates to other analysis tools. Given the complexity of 'deep analysis' and the absence of an output schema, the description leaves significant 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?
The only parameter, includeMinified, is a boolean with default false, but the description does not explain its meaning or effect. The phrase 'all JavaScript' could imply inclusion of minified files, but it does not explicitly connect to the parameter. Since schema description coverage is 0%, the description fails to compensate.
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 a specific action ('Perform deep analysis') on a clear resource ('all JavaScript') with a defined goal ('for animation patterns'). This distinguishes it from siblings like get_element_animations (element-specific) and trace_animation_execution (execution-focused), though it leaves what constitutes 'animation patterns' somewhat open.
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. Sibling tools like extract_animation_code, get_element_animations, and analyze_lenis offer more specific scopes, but the description does not mention these or any exclusions. The context is implied by the word 'all' but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral details. It only states that it generates code, but does not disclose what 'observed animations' means, what inputs affect output, whether it requires prior recording, or what the output format is. The behavior is underspecified for a tool that likely has side effects or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action. It is easy to parse and contains no fluff. However, it is so terse that it sacrifices necessary context, making it slightly under-specified for its informational needs.
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 context (2 optional params, no output schema, no annotations, and several sibling tools for animation extraction), the description is incomplete. It fails to explain the distinction from 'extract_animation_code', what 'observed animations' refers to, or what form the generated code takes. The agent likely needs more information to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% description coverage (only targetElement is described). The tool description adds no parameter detail whatsoever, leaving the 'framework' parameter's semantics to the enum alone. Since the description does not compensate for the missing schema documentation, the agent gets minimal guidance on how to set 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 specifies a clear verb 'Generate' and a concrete resource 'standalone code to recreate the observed animations'. It is not tautological and conveys the tool's core function. However, it does not explicitly differentiate itself from the sibling tool 'extract_animation_code', which may also generate code, so it loses a point on distinctiveness.
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 like 'extract_animation_code' or 'get_animation_css'. It does not mention prerequisites (e.g., having observed animations first) or any contextual cues for selection, 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?
No annotations are provided, so the description must fully disclose behavior. It only says 'generate a report,' which doesn't clarify if the report is returned, written to a file, requires set_output_directory, or has any side effects. This is insufficient for an agent to 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 one concise, front-loaded sentence with no unnecessary verbiage. It's efficient, though it sacrifices substance for 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 no annotations and no output schema, the description offers minimal context. It fails to explain what 'scroll animation analysis' covers, how the report integrates with sibling tools, or what the output looks like. The presence of sibling tools like set_output_directory suggests missing workflow 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?
Th input schema has a single 'format' parameter with an enum and default, which is self-explanatory, but the schema description coverage is 0% and the tool description entirely ignores the parameter. It does not explain what each format produces or that markdown is the 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 clearly states the tool's purpose: generating a comprehensive report of the scroll animation analysis. It uses a specific verb ('generate') and resource ('report'), but it doesn't differentiate from siblings like export_replicable_code or deep_script_analysis, which could also produce outputs.
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, no prerequisites (e.g., must run scroll_and_record first), and no mention of suitable workflows. It's a standalone statement without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states that the tool watches for style/transform changes, but does not clarify whether it returns data, attaches listeners, modifies the page, or requires interaction. There is no mention of side effects, permissions, or output format, leaving the agent with insufficient behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. It contains no redundant words or filler. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations) and its relation to sibling tools, the description is too sparse. It does not explain what the 'watch' produces, how it integrates with other tools like scroll_and_record, or what the user should expect after the duration expires. The agent lacks enough context 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 67% (selector and duration have descriptions, scrollThrough does not). The tool description adds no additional parameter semantics. The meaning of scrollThrough remains unclear (whether it scrolls the page automatically or requires manual scrolling), and the description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'watch a specific element' for 'style/transform changes during scroll.' This specifies the verb, resource, and scope, distinguishing it from siblings like scroll_and_record and get_button_animations. However, it lacks an explicit comparison to alternatives, so it doesn't fully differentiate itself.
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 only implies the context ('during scroll') but does not mention any exclusions, prerequisites, or why one might prefer this over scroll_and_record or get_animation_css. There is no explicit 'when to use' 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?
Annotations are absent, and the description only states 'Get detailed animation information' without disclosing side effects, return format, or whether it requires an open page or existing element. This leaves the agent unsure about the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and leaves important context unexplained: what 'detailed animation information' includes, whether a page must be loaded, and how it differs from related tools like get_animation_css. Despite the simple schema, the lack of output schema and annotations makes this incomplete for an agent to select 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?
The input schema fully documents the 'selector' parameter ('CSS selector for the element'), and the description adds no additional semantics. Baseline of 3 applies given 100% 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 action ('Get') and object ('detailed animation information') with a scoping selector. It distinguishes from siblings like get_animation_css (which likely returns CSS) by focusing on animation info for a specific element, but doesn't explicitly differentiate from all related tools.
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 provided. The description does not specify when to use this tool versus alternatives such as watch_element or trace_animation_execution, nor does it mention prerequisites 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 carries the full burden for behavioral disclosure. It states the action and scope but does not explain what 'animation state' entails, where the screenshot is saved, whether it requires an open page, or any side effects such as file creation.
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 superfluous content. It is front-loaded with the action and scope, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple capture tool with one optional parameter, the description gives enough to invoke it. However, with no output schema and no annotations, it lacks detail about output location or return value, leaving some ambiguity 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?
Schema coverage is 100% with one parameter fully described in the schema. The tool description adds no extra meaning beyond the schema, but the schema is sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('capture'), what is captured ('a screenshot and animation state'), and the scope ('at the current scroll position'). This distinguishes it from sibling tools like scroll_and_record, which imply scrolling behavior, and extract_animation_code, which deals with code extraction.
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. There is no mention of prerequisites, exclusions, or relationships with sibling tools such as scroll_and_record or set_output_directory. The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only mentions the methodological approach (AST parsing) and a quality claim. It does not describe return format, side effects, prerequisites, or whether it only operates on the current page source, which is a significant gap for a tool that extracts code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, scope, and method without any filler. It is appropriately sized for the tool's simple interface and earns every word.
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 moderate complexity (AST parsing, multiple libraries) and the lack of an output schema, the description is too minimal. It does not explain what the extracted code looks like, how it is returned, or how this differs from similar sibling tools, making it incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter (includeExternalScripts) is not mentioned in the description, and schema description coverage is 0%. The parameter's name is somewhat self-explanatory, but the description does not clarify what 'external scripts' includes or how the boolean affects extraction, leaving the agent without sufficient guidance.
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 ('Extract') and resource ('GSAP, ScrollTrigger, and Lenis code'), making the tool's purpose immediately clear. It also differentiates from sibling tools like get_scroll_triggers or analyze_lenis by focusing on extraction of code rather than live inspection, and the AST parsing detail adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extracting animation code and claims it is 'much more reliable than regex,' which hints at when to prefer this tool over naive methods. However, it does not explicitly state when to use this over sibling tools such as deep_script_analysis or trace_animation_execution, leaving the decision somewhat ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only gives a generic statement. It does not disclose whether the tool waits for elements, what delays are applied (though waitAfter exists), return values, side effects, or error handling. This is a significant gap for a UI interaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the purpose and lists the supported actions. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It leaves out parameter interaction details, waiting behavior, and expected results, making it inadequate 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 description coverage is 50% (only value and selector have descriptions). The description repeats the action enum values already present in the schema, adding no new information. It does not explain waitAfter or the relationship between value and type actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: performing page interactions (click, hover, scroll to element, type). This is specific and distinguishes it from sibling tools like open_page (navigation) and scroll_and_record (scrolling with recording).
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 list of actions implies when to use this tool (for click, hover, scroll, type), but there is no explicit guidance on when not to use it or what alternatives exist. The overlap with scroll_and_record is not addressed.
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 but only mentions the high-level actions. It does not disclose potential side effects such as triggering scroll events that might affect page behavior, nor does it explain what happens to the recorded video or screenshots. This lack of behavioral detail is a significant gap for a tool that manipulates page state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that avoids redundancy and gets straight to the point. It earns its place with no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having four parameters and no output schema or annotations, the description only provides a high-level summary. It omits information about the scrolling process (stepped, speed), the output artifacts (video file, screenshots), and any potential pitfalls, making it insufficient for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (stepDelay and scrollSpeed have descriptions). The description adds no parameter semantics, leaving recordVideo and captureScreenshots to rely on their names. The tool fails to explain how these booleans relate to the capturing behavior.
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 scrolls the entire page while recording video and capturing scroll-triggered animations. This is a specific verb+resource combination that distinguishes it from siblings like get_scroll_triggers or capture_current_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for full-page scroll capture but provides no explicit when-to-use or alternatives. An agent must infer from context that this is for recording animations during scrolling, but there's no guidance on when to prefer this over get_scroll_triggers or watch_element.
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 mention whether the directory is created if missing, whether existing settings are overwritten, or whether this affects subsequent operations. The description adds little beyond what the schema already states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description lacks any usage context or side-effect information. Given the low complexity, the description is minimally adequate but could benefit from noting how it affects the overall analysis workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and the description does not add meaning beyond the parameter's own description ('Path to the output directory'). Baseline of 3 is appropriate since the schema already documents the sole parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Set') and a specific resource ('directory where analysis output will be saved'). It is distinct from sibling tools that focus on page interaction and animation analysis, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites, or how it relates to other tools. The description only states what it does, leaving the agent without context for when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Analyze... configuration and behavior,' which implies a read-only operation but does not explicitly state safety, side effects, or what the analysis returns. It fails to communicate expected outputs or whether any page state changes occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary fluff. Every word earns its place, and the structure is appropriately minimal for a tool with no 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?
For a tool with no parameters and no output schema, the description covers the basic purpose, but it lacks detail about the analysis outcomes or expected behavior. Given the simplicity of the tool and the presence of many sibling tools, this is minimally adequate but leaves the agent guessing about what 'behavior' means or what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the baseline for 0 params is 4. The description adds contextual meaning by specifying the subject (Lenis smooth scroll) and what is analyzed (configuration and behavior), which is sufficient given there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Analyze' with a clear resource: 'Lenis smooth scroll configuration and behavior.' This clearly distinguishes it from sibling tools like extract_animation_code or get_scroll_triggers, which focus on different aspects of animation and scrolling.
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, exclusions, or scenarios where other sibling tools would be preferred. With 15 sibling tools, this absence of directional context is a significant gap.
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 what the tool does but does not mention that it is a read-only operation, whether a page must be open, potential side effects (e.g., reading DOM or triggering layout), or error conditions. Basic behavioral context is omitted.
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 one short, front-loaded sentence that immediately states the action and target. Every word carries meaning, with no filler or repetition of schema information. It is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the returned data looks like. It says 'with their configurations', giving a general idea but not a complete picture. It also omits contextual prerequisites (e.g., page must be loaded) that sibling tools imply. However, the tool is simple with minimal complexity, so a score of 3 reflects adequate completion with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is 4. The description adds slight semantic value by mentioning 'configurations', which hints at the return content, but no parameter details are needed. There is nothing to subtract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('all ScrollTrigger instances'), including the scope ('on the page') and the included detail ('with their configurations'). This distinguishes it from sibling tools like get_element_animations or analyze_lenis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool or how it compares to alternatives. Context signals list sibling tools, but the description does not mention any use cases or exclusions, leaving the agent to infer applicability solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It does state the primary side effect (closing the browser) and the cleanup of resources, which is good basic transparency. However, it does not detail what happens to ongoing operations, open tabs, or whether any state is persisted, leaving some ambiguity for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that covers both the action and the cleanup aspect with no wasted words. It is concise and directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, and only one action), the description is sufficiently complete for an agent to understand what the tool does. It covers the primary purpose and the intended resource cleanup without needing to explain return values or complex side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. There is no parameter information needed, and the description is not required to compensate for any schema gaps. A baseline of 4 is appropriate given that no parameters exist.
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 closes the browser and cleans up resources, which is a specific action on a clear resource. It distinguishes itself from sibling tools like open_page and interact_with_page by focusing on teardown. However, 'clean up resources' is somewhat vague and could be more specific about what it 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?
There is no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used at the end of a browsing session or that it will invalidate any handles from open_page. The usage is implied by the name and context, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions that the browser is headless and that the tool initializes the browser and navigates to the URL. However, it omits details about the return value, potential errors, timeouts, or the effect on an existing browser session.
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, tightly written, and front-loads the core action. 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?
The description provides the basic purpose but lacks an explicit statement of what the tool returns (no output schema), and it doesn't explain how this fits the workflow beyond 'for analysis.' For an agent that needs to chain tools, the absence of return-value information is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (100% coverage), so the tool description adds no extra parameter semantics. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: opening a webpage in a headless browser and navigating to it. This distinguishes it from sibling tools like scroll_and_record and interact_with_page, which perform different actions on the page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is an entry point ('initializes the browser,' 'for analysis') but does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It implies a read-only extraction from stylesheets, which is non-destructive, but it does not describe return format, coverage of inline styles, or potential side effects like performance impact. The verb 'extract' provides some behavioral clarity but not rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, and the description conveys the core function. However, the absence of an output schema means the description could slightly elaborate on the returned data (e.g., list of animation names vs. raw CSS), but overall it is adequate for a straightforward extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly omits parameter details, and no extra parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Extract") and a clear resource ("all CSS animations and keyframes from the page stylesheets"). It clearly differentiates from sibling tools like 'get_element_animations' (per-element) and 'extract_animation_code' (likely targeted code extraction) by specifying page-wide scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as 'extract_animation_code' or 'get_element_animations'. The description states only the function, not the intended use case or exclusions.
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-scroll-analyzer MCP server](https://glama.ai/mcp/servers/rob-kingsbury/mcp-scroll-analyzer/badges/card.svg)](https://glama.ai/mcp/servers/rob-kingsbury/mcp-scroll-analyzer)

Score Badge

Copy to your README.md:

[![mcp-scroll-analyzer MCP server](https://glama.ai/mcp/servers/rob-kingsbury/mcp-scroll-analyzer/badges/score.svg)](https://glama.ai/mcp/servers/rob-kingsbury/mcp-scroll-analyzer)

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/rob-kingsbury/mcp-scroll-analyzer'

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