UserFlow MCP

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation4/5
Most tools have distinct purposes: session control (start/step/end), observation (get_page_state), analysis (accessibility_audit, inspect_storage, export_har, compare_screenshots), and persona/device management. The only possible confusion is between start_session and quick_scan, both navigate but one establishes a session; descriptions clarify this. Overall, tools are well-differentiated.
Naming Consistency3/5
Tool names are predominantly verb_noun (start_session, get_page_state, create_persona), but some deviate with adjective_noun or single-word names (quick_scan, auto_walk, step). All use snake_case, which maintains readability, but the inconsistency in grammatical pattern reduces predictability.
Tool Count4/5
14 tools cover the full user flow testing lifecycle without feeling bloated. Each tool addresses a specific concern: session control, page inspection, accessibility, storage/network analysis, persona management, and automated comparisons. The count is appropriate for the comprehensive feature set.
Completeness4/5
The tool surface covers the core lifecycle (start/step/end), plus useful extensions like accessibility audits, storage/HAR inspection, and persona-based automated testing. Minor gaps exist (no update/delete persona, no resize viewport beyond device profiles), but they don't hinder the primary use case. Overall, the domain is well-covered.
Average 4/5 across 14 of 14 tools scored.
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 is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions identifying tracking cookies and calculating cookie size, but does not disclose potential side effects, read-only guarantees, or limitations. It does not state whether any storage data is modified or cleared, which is a notable gap for an inspection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the primary action, and no redundant wording. Every sentence adds value, second sentence provides useful detail about tracking cookies and size calculation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should hint at the return format, but it does not. It also lacks usage constraints or edge-case behavior. However, the tool's purpose is clear and the parameter set is minimal, so it is not severely incomplete, but there are gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter (session_id) with 100% description coverage, so the schema already fully documents it. The tool description adds no additional meaning to the parameter itself, but since coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'inspect' and the resources 'cookies, localStorage, and sessionStorage' for the current page. It goes beyond a simple restatement by adding specific outcomes ('Identifies tracking cookies and calculates total cookie size'), which differentiates it from sibling tools like get_page_state or export_har.
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 the current page') but does not explicitly state when to prefer this tool over alternatives or when not to use it. There's no mention of exclusions or alternatives, so while the context is clear, the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears the full burden. It discloses that the tool returns 'the resulting page state with a new screenshot' and that there is a 'Smart selector fallback' that tries alternative strategies on CSS selector failure. However, it does not discuss potential side effects of actions, whether they are reversible, or any error handling beyond the fallback, which is a notable gap for a tool that executes mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 100 words, starts with a clear lead sentence, and lists actions in a compact block. The v0.3 version note adds useful behavioral information but is somewhat tangential to core usage. Overall, it is efficient without being bloated, scoring a 4.
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 moderately complex with 8 parameters, no output schema, and no annotations. The description covers the core purpose, action categories, and a key behavioral fallback, and the schema fills in parameter details. However, it does not explain the session lifecycle (e.g., that a session must exist before this step), nor does it describe the response format beyond 'resulting page state with a new screenshot'. Given the sibling tools (start_session, end_session), a brief usage context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 8 parameters (100% coverage), including the action enum and values for `value`. The description adds no new parameter-level semantics; it only restates the action list and mentions optional recording of persona thoughts/friction, which are already described in the schema. Therefore, it aligns with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute one step in a session' and enumerates nine specific actions, distinguishing it from sibling tools by focusing on action execution and returning a screenshot. It uses a specific verb (execute), a resource (one step in a session), and a scope (list of actions), which makes its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage within a session ('Execute one step in a session') and lists actions, but it does not explicitly state when to use this tool versus alternatives like get_page_state or auto_walk, nor does it provide exclusions or alternative recommendations. The context is clear but not prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the use of axe-core and enumerates the return payload (score, violations, fixes), which is useful, but it does not explicitly state whether the audit is read-only, how failures are surfaced, or any rate limits or permission requirements.
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 action, and every word adds value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description preemptively explains what the tool returns (score, violations, fixes), covering the main agent needs. It does not mention error cases or edge conditions, but for a straightforward audit tool with only two parameters, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (session_id, wcag_level with enum and default), so schema coverage is 100%. The description adds no additional parameter-level detail beyond what the schema provides, so the baseline 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?
Description names a specific action ('Run a WCAG accessibility audit') and target ('current page of a session'), and uniquely identifies this as the accessibility-focused tool among siblings. It clearly distinguishes from tools like quick_scan or compare_screenshots.
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 requires an active session ('current page of a session') and allows choosing WCAG level via the schema. However, it does not explicitly state when to prefer this over alternative tools like quick_scan, nor does it mention any 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?
With no annotations, the description carries the full burden. It discloses key behavior (heuristic navigation, no AI reasoning, autonomous execution, returns a report), but it does not mention side effects, permissions, rate limits, or whether the walk might interact with the page beyond navigation. This is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key differentiator ('Fast automated walk using heuristic-based navigation (no AI reasoning)'), and each sentence adds meaningful information. There is no wasted text.
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 documented parameters, but lacks an output schema and annotations. The description mentions 'returns a report' without detailing what the report contains, and does not clarify whether the walk requires or creates a session relative to sibling tools like start_session and step. This leaves important gaps for a tool that runs autonomously.
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 provides descriptions for all three parameters (url, persona, max_steps), giving 100% coverage. The description adds no parameter-specific information beyond what the schema already documents, so the baseline score 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 performs an 'automated walk using heuristic-based navigation (no AI reasoning)' and 'runs the full flow autonomously and returns a report.' This specifies the verb (walk), the resource (full flow), and distinguishes it from step-by-step alternatives among siblings.
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 gives a usage condition: 'Use this for quick scans when you don't need to drive step-by-step.' This clearly indicates when to use it, though it does not name specific alternative tools or provide exclusions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the heuristic walker behavior and the speed/nuance trade-off, but does not explain output format, side effects, or prerequisites such as whether personas must already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and immediately followed by a usage trade-off. Every word contributes, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description omits what the comparison output looks like and whether personas need to be pre-created. The complexity of an automated walker warrants more detail, though the core purpose is conveyed.
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 schema itself documents all parameters. The description adds context about comparing multiple personas on the same URL, but does not provide additional meaning beyond the schema definitions.
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 runs an automated heuristic walker for multiple personas on the same URL and compares their experiences. It also distinguishes from step-by-step simulation via the trade-off note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool ('Fast but less nuanced than step-by-step simulation'), implying it is the quick option compared to a more detailed alternative. It does not explicitly name the alternative tool, but the guidance is sufficient for selection.
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 burden of disclosure. It states that it creates a persona and returns the definition, but it does not reveal whether the persona is persisted, if it overwrites existing personas, or any side effects. Given the existence of list_personas, persistence is implied but not 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 two sentences, front-loaded with the tool's purpose, and includes the essential return value. Every word earns its place; no redundancies or fluff.
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 has 10 parameters, no output schema, and no annotations, the description provides basic purpose and return value but lacks details about side effects, persistence, or workflow context beyond mentioning start_session. It is adequate but not rich enough for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions some key parameters (name, goals, tech literacy, patience, device, accessibility needs) but does not add additional semantic meaning beyond the schema. It omits some parameters like description, background, and behavior_notes, so it doesn't fully 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 tool's function: 'Create a custom persona for testing.' It specifies the resources (persona) and distinguishes itself from siblings like list_personas and start_session by noting the return value is 'to use with start_session.' The verb 'create' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to create a persona for testing) and indicates its role in the workflow by returning a definition for start_session. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core operation and return values, but gives no details on constraints, performance, or side effects. For example, it does not mention handling of corrupted images, file size limits, or whether the diff image is returned as base64 or a path. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary verb and resource, and every sentence adds value. There is zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description appropriately explains the return format (match percentage and diff image). It does not specify how the diff image is delivered (e.g., base64 string vs. file path), which is a minor gap. Overall, it is sufficiently complete for a straightforward comparison tool with well-described parameters.
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% for all three parameters (screenshot1, screenshot2, threshold), so the schema already documents them fully. The tool description adds no additional parameter-level semantics beyond what the schema provides, so a 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 the action ('Compare two base64 PNG screenshots pixel-by-pixel') with a specific resource (screenshots) and method (pixel-by-pixel). It explicitly mentions the output (match percentage and visual diff image), distinguishing it from sibling tools like compare_personas_auto which compare personas rather than screenshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Useful for detecting UI regressions or verifying changes.' This tells when to use the tool. However, it does not explicitly mention alternatives or when not to use it, stopping short of a full 5.
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 alone convey safety and side effects. It states the export behavior but does not explicitly say it is read-only or describe error behavior for invalid session IDs. The scope 'all network requests' adds some context, but transparency is limited.
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 are used, with the action and output format front-loaded. The second sentence lists practical use cases. No redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool, the description covers the output format (HAR 1.2 log) and use cases. It is missing an explicit note about whether the session must be active or if there are side effects, but overall it is sufficient for such a targeted 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?
The schema has one required parameter 'session_id' with only 'Session ID' as description. The tool description ties the session concept via 'during the session' but does not elaborate further. With 100% schema coverage, the baseline is 3, and the description adds marginal semantic 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 specific verb 'Export' and the resource 'all network requests captured during the session', with a defined output format 'HAR 1.2 log'. This distinguishes it from siblings like get_page_state or inspect_storage, which target different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'analyzing network performance, finding slow requests, and debugging API calls'. It does not mention alternatives or exclusions, but the context is clear enough for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing that it closes the browser, computes metrics, and returns a full transcript. It could add irreversibility or validation details, but the main side effects are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The version note adds useful context without waste, though some minor redundancy exists ('full' and 'all'). Overall efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by detailing what the report includes (Core Web Vitals, accessibility, network, console errors). It covers purpose, behavior, and output adequately, though it omits prerequisites or error conditions. Still complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are described in the input schema with 100% coverage, so the description does not need to add extra parameter meaning. It adds no parameter-specific details beyond the schema, which is sufficient. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'End a session and get the final report', which specifies the action and resource. It distinguishes itself from siblings like start_session by describing the closing behavior and specific outputs (friction score, emotional arc, transcript).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a session should be ended and a report is needed) through its clear statement of behavior. However, it does not explicitly mention when not to use it or alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the non-mutating nature ('without performing any action') and implies safety for repeated calls, but it does not detail what specific state data is returned, which would be useful given no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states purpose and use cases without redundancy. Every phrase earns its place, and it remains front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with no output schema, the description covers the main usage context and side-effect profile. It stops short of detailing the return structure of 'page state,' which would enhance completeness, but the information provided is sufficient for tool 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 coverage is 100% with clear parameter descriptions for `session_id` and `full_page`. The tool description adds no additional parameter semantics beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('current page state and screenshot'), and explicitly distinguishes from action-performing siblings with 'without performing any action.' The use cases for re-examining and lazy-loaded content further clarify its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases ('re-examining the page or checking if lazy-loaded content has appeared'), establishing when to invoke it. It implies a contrast with action tools but does not name specific alternatives or state exclusions, so it falls short of 'explicit when-not/alternatives.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It transparently describes the stateless nature, navigation, screenshot capture, and extraction of page elements. However, it does not mention potential side effects like network requests or cookie handling, though for a scanning tool this is likely sufficient.
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 remarkably concise, front-loaded with 'Fast single-page scan,' and every sentence provides essential information. It covers the actions, the output, and the stateless nature without any fluff or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description adequately summarizes the behavior and return type ('Returns everything to you for analysis'). It does not explicitly state return structure or error handling, but the core functionality is clear, and the statelessness is highlighted. Slightly more detail on response format would push it to a 5.
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 all parameters are already documented. The description adds general context about the tool's purpose but does not enrich the understanding of any specific parameter (e.g., how full_page or wait_ms affect the screenshot timing), so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'Fast single-page scan' and details its actions: navigate, capture screenshot, extract interactive elements, headings, forms, and error messages. It distinguishes itself from sibling session-based tools by explicitly stating 'no session state required,' making its scope and resource clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick, stateless scans without the overhead of session management. It contrasts with sibling tools like start_session and step by highlighting the lack of session state, but it does not explicitly name alternatives or specify 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool opens a browser, navigates to a URL, returns a snapshot with metrics, and provides a persona definition for roleplaying. It also mentions v0.3 device emulation support. This is transparent about the immediate effects and outputs, though it does not discuss side effects like session lifecycle or resource cleanup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized. It opens with a clear action, lists return values, then gives the workflow and a version-specific note. Every sentence adds value without redundancy, and the structure is scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently describes the return payload (first page snapshot, screenshot, Core Web Vitals, accessibility score, network summary) and outlines the overall workflow. It also provides version context for device emulation. It does not cover all edge cases or prerequisites, but for a session-start tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all five parameters, so the description adds little new semantic meaning. It does mention that device_profile supports device emulation and advises using list_devices, but this is more of a reference than an enrichment of parameter semantics. This aligns with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Start a user flow session. Opens a browser, navigates to the URL, and returns the first page snapshot...' This is a specific verb+resource with a defined scope. It also distinguishes itself from siblings by outlining the workflow 'start_session → step → end_session' and positioning this as the entry point.
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 gives explicit context for when to use this tool: it begins a session and then delegates future actions to the 'step' tool. The workflow line and the note about device_profile using list_devices provide practical usage guidance, though it does not explicitly list exclusions or alternative tools for simpler tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly states the tool performs a read-only listing operation ('List all...') and adds behavioral context by enumerating the categories of profiles. However, it does not describe the return format or any edge cases, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the primary purpose, the second provides usage guidance. It is front-loaded, concise, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description provides sufficient context: it explains what the tool does, the categories of devices, and how the output connects to start_session. It lacks explicit return structure but the 'device key' mention helps.
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 input schema is empty. The description correctly omits parameter details; the baseline of 4 applies since no parameter information is 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 the specific verb 'List' and identifies the resource as 'all available device emulation profiles' with examples (phones, tablets, desktops). It also distinguishes itself from siblings by tying the output to start_session's device_profile parameter, making its role clear.
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 instructs to 'Use the device key with start_session's device_profile parameter', which tells the agent when to use this tool (before starting a session) and how to apply its results. It does not explicitly mention alternatives or when-not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly discloses the read-only listing behavior, the scope (built-in personas only), and the content (full trait definitions). For a simple list operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and immediately followed by practical usage guidance. Every word earns its place without redundancy.
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?
For a zero-parameter, no-output-schema tool, the description fully covers purpose, usage, and expected content. It also ties into sibling tools (start_session) effectively, making it self-contained for an AI agent.
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 there is no schema burden. The description adds useful context about what the returned list covers, which is sufficient given 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 a specific verb ('List') and resource ('all built-in personas with their full trait definitions'), clearly distinguishing this from siblings like create_persona and compare_personas_auto by focusing on existing built-in personas.
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 states when to use the tool: 'to choose a persona for start_session, or to understand each persona before roleplaying as them.' It implies the alternative of creating custom personas via create_persona, but does not explicitly name it as a when-not-to-use case.
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:

[![userflow-mcp MCP server](https://glama.ai/mcp/servers/prembobby39-gif/userflow-mcp/badges/card.svg)](https://glama.ai/mcp/servers/prembobby39-gif/userflow-mcp)

Score Badge

Copy to your README.md:

[![userflow-mcp MCP server](https://glama.ai/mcp/servers/prembobby39-gif/userflow-mcp/badges/score.svg)](https://glama.ai/mcp/servers/prembobby39-gif/userflow-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/prembobby39-gif/userflow-mcp'

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