peek

by Cubenest

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct aspect of browser session recording: action execution, session listing, error retrieval, DOM snapshots, history tracking, authorization, and repro generation. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., execute_action, get_session_summary, list_recent_sessions), making them predictable and easy to understand.
Tool Count5/5
With 10 tools, the server provides a comprehensive yet focused set for browser session analysis and interaction—enough to cover core workflows without being overwhelming or too sparse.
Completeness4/5
The tool surface covers session listing, detailed error/network analysis, DOM inspection, action execution, and repro generation. Minor gaps like session deletion or full error browsing are not critical for the primary use case.
Average 4.4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 134 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that the tool returns test source as text and notes the limitation that only single-value <select> is represented. This adds useful behavioral context not covered by annotations.
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 long, front-loading the core purpose and then adding optional details and a note. Every sentence is informative and there is no 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?
For a tool with 3 parameters and no output schema, the description adequately explains what it does, what it returns, and a key limitation. It does not mention the source of sessionId but the schema references list_recent_sessions. Overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameters. The description reiterates the optional timestamp filtering but does not add significant new meaning beyond what the schema provides.
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 generates a runnable Playwright test reproducing user actions, specifying exactly which actions are included (clicks, typing, navigation, <select> changes). This distinguishes it from sibling tools like execute_action or get_dom_snapshot.
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 used to generate test code from session data but does not explicitly mention when to use it over alternatives or provide exclusions. The use case is inferable from the nature of the tool, but no direct guidance is given.
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?
Description discloses output format (JSON rows with specific fields) and clipping of url and errorText to 300 chars. Annotations already set readOnlyHint=true, and the description adds detail about ordering (oldest first) and inclusive transport errors. No contradictions.
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: first defines scope and ordering, second describes return format and clipping. Every word adds value; no redundancy or unnecessary details. Properly front-loaded with key 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?
Without an output schema, the description provides sufficient structure of returned rows. Covers filtering, ordering, and limit. Lacks mention of error conditions or performance, but for a list tool, it is adequately 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?
Schema coverage is 100%, so parameters are well-described in schema. The description adds context about default values and transport errors always being included, but these are also present in the schema descriptions. Minimal additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Title 'List failed network requests' and description 'List failed or notable network requests...' clearly state the verb (list) and resource (network requests in a session). It distinguishes from sibling tools like get_session_console_errors by specifying network failures with HTTP status thresholds and transport errors.
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 explains the filtering condition (status >= statusGte, transport errors always included) and defaults, but does not explicitly state when to use this tool versus alternatives like get_session_console_errors. Usage context is implied by name and siblings, not explicitly contrasted.
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?
Annotations declare readOnlyHint=true, and the description adds the return format and session context without contradicting annotations.
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 defines purpose and resource, the second provides a key usage instruction. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and return shape, but lacks detail on the structure of individual changes and ordering, though adequate for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds extra guidance on using 'op' to filter changes, enhancing the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a timeline of attribute and text changes for a DOM node matching a CSS selector, distinct from siblings like get_dom_snapshot or get_session_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a usage hint for the 'op' parameter but does not explicitly contrast with sibling tools or state when to avoid using 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?
Annotations indicate readOnlyHint=true; description confirms read-only listing. Adds behavioral details: free-text field clipping (origin 100, url 300, title 200 chars) and origin scoping under client roots. No contradiction. Provides useful behavioral context beyond annotations.
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?
Extremely concise and well-structured: starts with action, then output format, then key behavioral notes, then usage recommendation. Every sentence is informative 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?
No output schema, but description sufficiently explains return format and fields. Covers key behaviors (clipping, scoping) and positions the tool in the workflow. Complete for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds minor value: clarifies that omitting origin means 'across all recorded origins (subject to client roots scoping)' and that limit defaults to 10 with newest-first ordering.
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's purpose: listing browser sessions, newest first. It specifies the output format (compact JSON rows with fields) and distinguishes itself from sibling tools by positioning as the entry point for session-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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: start here to get a sessionId, then call get_session_summary. Mentions origin filtering and client-root scoping, suggesting when to use filters. Lacks explicit when-not or alternative conditions, but 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?
Annotations declare readOnlyHint=true, which the description does not contradict. The description adds behavioral traits beyond annotations: it applies mutations on top of the nearest full snapshot, returns JSON with specific fields (baseSnapshotTs, mutationsApplied, html), clips HTML to 24000 chars, and fails if no full snapshot exists. This provides useful context for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and includes essential details: timestamp usage, mutation application, return format, clipping limit, and failure condition. Every sentence adds value with 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?
Given the tool has 3 parameters, no output schema, and annotations provide readOnly hint, the description adequately covers the return structure and limits. It could mention behavior for invalid selectors, but overall it is complete enough for typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters. The description adds meaning: for ts, it specifies 'Epoch-ms timestamp' and suggests sources (get_session_summary, error rows, get_user_action_before_error). For selector, it clarifies behavior ('return only that subtree. Omit to return the full document'). This adds value beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Reconstruct the page DOM as it existed at a timestamp (or a selector subtree within it) and return it as HTML.' This is a specific verb (reconstruct) and resource (DOM at a timestamp), and it distinguishes from siblings like get_session_summary (metadata) or query_dom_history (likely different).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it uses timestamps from get_session_summary, error rows, or get_user_action_before_error, and mentions failure condition if no full snapshot exists. However, it does not explicitly state when not to use this tool or suggest alternatives, though the context is sufficient for most cases.
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?
Annotations indicate read-only. The description adds details on return format (JSON rows with fields), clipping limits, and paging via 'since'. No contradictions.
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 purpose, efficient in conveying key details without waste.
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?
Covers purpose, output format, clipping, paging, and links to a sibling tool. Lacks explicit return value description, but enough given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds context for 'since' (paging) and 'limit' (max 200, default 50), providing meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists console error messages from a session, oldest first, and distinguishes from sibling tools like get_session_network_errors and get_session_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly suggests using get_session_summary for error counts, providing an alternative. However, it does not cover when not to use this tool in other contexts.
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?
Annotations declare readOnlyHint=true, which the description does not contradict. Beyond annotations, the description discloses the return format (JSON with errorId, errorTs, actions) and behavioral details: actions are the last N (default 10, max 50) preceding the error and include click/type/navigate. This adds meaningful context.
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 three sentences, front-loaded with core purpose, then details on usage and output format. Every sentence adds information without redundancy. 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?
Despite lacking an output schema, the description explicitly outlines the return JSON structure. It covers inputs (sessionId, errorId, window) and their origins. The tool is straightforward, and the description adequately prepares an agent to use it correctly. Minor omission: no mention of rate limits or potential errors, but readOnlyHint mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds value by explaining that 'window' refers to the number of preceding user actions to return, and that errorId comes from a specific sibling tool (get_session_console_errors). It also implicitly clarifies sessionId's origin via sibling context.
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 reconstructs user actions (click/type/navigate) right before a console error, specifying the resource and purpose. It distinguishes from siblings like get_session_console_errors (which gets error IDs) and generate_playwright_repro (another reconstruction tool) by focusing on the 'window' of actions preceding the error.
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 get errorId from get_session_console_errors first, providing a clear prerequisite. It implies when to use: after obtaining a console error and wanting to understand its trigger. While it doesn't explicitly list alternatives, the context of sibling tools makes it clear when this tool is appropriate.
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?
Annotations declare readOnlyHint=true, so the description doesn't need to restate. It adds that the tool returns a structured JSON summary, which is helpful beyond annotations.
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-load the purpose and usage guidance, with zero wasted words. Efficient and well-structured.
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?
Despite no output schema, the description covers the main output fields (pages, clicks, errors). It references sibling tools and provides a complete picture for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for sessionId. The description's mention of 'one session' adds context but no new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets a narrative summary of a session, listing specific data points (pages, counts, errors). Distinguishes from siblings by positioning as an overview tool before drilling into error-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this first for an overview before drilling into get_session_console_errors or get_session_network_errors, providing clear 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: logging to ~/.peek/audit.log on every call, return of one-shot token or denial, and the pre-authorization use case. Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are not contradicted; the description adds valuable context.
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 that front-load the core function, mechanism, and usage. No wasted words; every sentence earns its place. The structure logical: what -> how -> when.
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 complexity (multiple action types, permission levels, logging, token concept), the description covers the essential points: authorization flow, token usage, logging, and context (Level-3 or pre-authorize). Lacking explicit mention of what happens on timeout or error, but overall sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good individual parameter descriptions (e.g., sessionId description explains its origin and purpose). The tool description adds little beyond the schema, so baseline 3 is appropriate. It does not explain the action sub-schemas but the schema already handles that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: requesting user authorization for a browser action via a side-panel banner. It distinguishes itself from sibling execute_action by specifying it returns a token or denial, and it uses a specific verb ('authorize') on a specific resource ('browser action').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'Use before execute_action when the origin is at permission Level 3, or to pre-authorize.' This provides clear context and differentiation from siblings, and implies not to use it when permission level is lower or when direct execution is allowed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description expands on annotations (destructiveHint=true) by explaining the destructive override prompt. It also adds that every call is recorded to an audit log, which is not in annotations. No contradiction with annotations.
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 paragraph that efficiently covers the core purpose, permission model, and audit logging. It is front-loaded with action types. Some minor restructuring could improve readability, but it remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple action types, permission levels), the description covers the necessary behavioral context. It does not detail each action type, but the schema handles that. Output schema is absent but not critical. The coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context beyond schema: sessionId comes from list_recent_sessions, confirmToken is from request_authorization. This enhances parameter understanding slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute an action (click/type/navigate/...)' in the user's live browser. It uses a specific verb+resource and lists examples, distinguishing it from sibling read-only or analysis tools like get_dom_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it details permission levels (3+, 4), behavior of confirmToken banner vs auto-allow, and the destructive-action override always prompting. This helps the agent decide when and how to use the tool, including prerequisites.
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:

[![rrweb-stack MCP server](https://glama.ai/mcp/servers/Cubenest/rrweb-stack/badges/card.svg)](https://glama.ai/mcp/servers/Cubenest/rrweb-stack)

Score Badge

Copy to your README.md:

[![rrweb-stack MCP server](https://glama.ai/mcp/servers/Cubenest/rrweb-stack/badges/score.svg)](https://glama.ai/mcp/servers/Cubenest/rrweb-stack)

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/Cubenest/rrweb-stack'

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