shadow-monitor-mcp

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation5/5
Each tool targets a distinct aspect of the diagnostic bundle: loading, overview, errors, network, console, user actions, replay, and semantics. There is no overlap; every tool has a clear and separate purpose.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., load_bundle, find_errors, get_network_request), but bundle_metadata and bundle_overview use noun_noun, introducing a slight inconsistency. Overall, the pattern is clear and predictable.
Tool Count5/5
With 10 tools, the set is well-scoped for a diagnostic bundle analysis server. Each tool fills a necessary role without redundancy or bloat, covering loading, overview, detailed inspection, and replay.
Completeness4/5
The tool set covers the core workflows of loading, overview, error analysis, network/console inspection, user actions, and replay. Minor gaps exist, such as a lack of a full event search, but the essential functionality for analysis is present.
Average 4.2/5 across 10 of 10 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on July 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

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 accurately states the tool returns metadata without event data, but omits important context such as that the bundle must be loaded (implied by 'loaded bundle') and that bundleId is optional if only one bundle is loaded. These are behavioral constraints that should be explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that lists many fields, which is efficient but could be more readable with structure (e.g., bullet points). No irrelevant information, earns its place.
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 provides a solid overview of return fields (schema version, generation time, etc.), covering the main components. It is fairly complete for a metadata tool, though some field details (e.g., what counts include) are implied rather than explicit.
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% (single optional bundleId with description). The tool description adds no extra meaning beyond the schema's own parameter description. 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 tool retrieves 'lightweight metadata for a loaded bundle without any event data' and enumerates specific fields, effectively distinguishing it from sibling tools like bundle_overview or those that return events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; the description simply lists what it returns. It does not specify context like 'use for a quick summary before fetching events' or mention that a bundle must be loaded first.
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?
The description discloses format handling, reuse on same path unless reload=true, and the need for a passphrase. However, with no annotations provided, it omits potential side effects (e.g., memory usage), error conditions, or permission requirements. The level of detail is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the core action and returns, second clarifies reuse and reload. Information is front-loaded and every sentence contributes meaningfully. No extraneous content.
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 adequately covers input formats, return of bundleId and summary, and reload behavior. It does not detail the summary contents or error scenarios, but for a load tool these are secondary. The description feels comprehensive for typical use.
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 value beyond schema by explaining when `passphrase` is needed (encrypted bundles) and the `reload` parameter's effect on handle reuse. This enhances understanding of parameter usage.
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 loads and indexes a Shadow Monitor diagnostic bundle from a local file path, specifying supported formats (JSON, gzip, encrypted) and the return of a bundleId and summary. This differentiates it from sibling tools by positioning it 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the bundleId is used by other tools, suggesting this should be called first, but it lacks explicit when-to-use or when-not-to-use guidance (e.g., 'use this before bundle_metadata'). No alternative strategies are mentioned.
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 provided, so description carries the burden. It discloses it is a cheap probe, does not index events, and returns specific fields. Does not mention side effects (likely none) or permissions, but is transparent about its scope.
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 with critical information front-loaded. Every sentence serves a purpose: first states function and return, second clarifies non-indexing and usage hint. No unnecessary 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 no output schema, the description lists return fields. It covers behavior (no indexing) and usage. Does not mention error cases or format of return, but is sufficient for a simple probe 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 descriptions for both parameters. The description adds little beyond schema: it rephrases path as 'local path' and mentions optional passphrase for encrypted exports. No additional semantic depth.
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 checks if a local path is a workable Shadow Monitor diagnostic export (with specific file extensions) and lists the return fields. It distinguishes itself from 'load_bundle' by positioning as a preliminary probe.
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?
Explicitly says 'use before load_bundle when the path is unfamiliar, or when load_bundle might fail', providing clear context. Does not explicitly exclude other siblings, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the size warning and that it doesn't alter get_user_actions. However, it omits idempotency, error handling, or authorization needs. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with no fluff. Front-loaded with purpose, then parameter guidance and behavioral notes. Every sentence earns its place.
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 6 parameters, no annotations, and no output schema, the description covers identification methods, size mitigation, and relationship to get_user_actions. Missing return value specifics (e.g., FullSnapshot details) but acceptable 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%, so baseline is 3. The description adds context: actionId references get_user_actions, fromTs/toTs are explicit timestamps, bundleId is optional when one bundle loaded, actionIndex is an alternative 0-based index into semantics.userActions. This meaningfully supplements 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 returns raw rrweb events for a user-action step with FullSnapshot anchor prepended. It distinguishes from sibling get_user_actions, which only returns lightweight pointers.
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 clear guidance on how to identify the step: pass actionId from get_user_actions or explicit fromTs/toTs. Mentions optional maxEvents for large output. Lacks explicit when-not-to-use or alternatives beyond the one sibling mentioned.
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 full burden. It discloses returned fields (level, message/args, stack trace, URL), which is helpful. However, it does not state that the operation is read-only or has no side effects, which would be useful for an agent.
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. Every sentence earns its place, 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 no output schema, the description adequately covers the key outcome and fields. It could slightly improve by stating the return format (e.g., object), but it is sufficiently complete for an agent to understand the tool's purpose.
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% (baseline 3). The description adds value by explaining id format (string like 'e_3068' or bare number) and its origin from search results. It also clarifies that redact overrides field hygiene, adding context 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 returns full detail of one console event by event id. It uses a specific verb ('Return') and resource ('console event detail'), and distinguishes from siblings like find_errors (listing) and get_network_request (different event type).
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 after search/find_errors (id from a row), but does not explicitly state when to use or not use this tool versus alternatives. No exclusion criteria or comparison to siblings is provided.
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 discloses internal behavior: prefers pre-computed semantics (schema 2/3) and falls back to scanning events for schema 1. This goes beyond basic read-only indication and helps agents understand performance implications.
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 efficiently convey purpose, internal behavior, and usage guidance. No redundant information; every phrase adds value.
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 lists all major aggregates (page, capture window, network breakdown, errors, etc.) so agents know exactly what to expect. The fallback behavior adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no extra parameter details. The bundleId parameter is well-documented in the schema, so the description doesn't need to augment it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'high-level aggregates for a loaded bundle' and lists specific metrics (page, capture window, event counts, etc.), distinguishing it from sibling tools that focus on individual aspects (e.g., find_errors, get_network_request).
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?
Explicitly advises to 'Use this first to orient before drilling in', giving clear usage context. While it doesn't list exclusions or alternatives, the guidance is strong enough to imply this is the starting point.
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 full burden. It discloses that filters match raw values, displayed URLs are field-hygiened, and the row id format (e.g., 'e_3069'). It doesn't mention auth needs or rate limits, but for a search tool these are reasonable omissions.
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 two sentences, front-loaded with core purpose. The second sentence lists filters compactly, but could be better structured (e.g., bullet points or grouping). Still, it's concise and informative.
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 13 optional parameters and no output schema, the description covers return format, filter combination, pagination, and cross-reference to get_network_request. It doesn't specify default sorting or empty-result behavior, but overall it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 69%, the description adds value by summarizing filter options and providing special behavior details (e.g., word-boundary matching for bodyContains numeric needles). This goes beyond the schema's basic 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 verb 'Filter' and the resource 'captured network requests', specifies the compact rows returned (id, time, method, status, etc.), and distinguishes from sibling tool get_network_request which fetches full detail.
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 explains how to combine filters and paginate with limit/offset, and directs users to get_network_request for full details. However, it doesn't explicitly state when not to use this tool or mention alternatives like find_errors for error-focused searches.
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 fully discloses error definitions, row structure including event ID and responseBodyPreview, and optionality of bundleId. It explains behavior but omits pagination or ordering details.
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?
Four well-structured sentences front-load the main purpose, then detail error definitions and row format. No redundant or unnecessary 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?
The description covers error definitions, row structure, and parameter context well. Missing explicit output format and ordering direction, but overall adequate for a 3-param tool with 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%, and the description adds context: bundleId's optionality when one bundle loaded, includeWarnings meaning, and references to load_bundle. It doesn't add to limit 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?
The description clearly states the tool returns network and console errors in time order, defines each error type explicitly, and distinguishes from sibling tools by mentioning event IDs for get_network_request/get_console_event.
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 context on when to use (for chronological error list) and hints at alternative tools (detail calls via event ID), but lacks explicit don't-use guidance or comparison with search_network.
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 full burden and discloses key behaviors: includes headers/bodies, truncation with original length noted, and redaction with optional override. It lacks detail on error handling or authorization, but covers major traits.
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?
Four sentences with efficient structure. First sentence states main purpose, subsequent sentences add key details. No redundant or 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 no output schema, the description covers what is returned (headers, bodies) and important behaviors (truncation, redaction). It lacks details on error responses or exact return format, but is sufficient for a focused detail 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% (baseline 3). The description adds practical examples for the id parameter (e.g., 'e_3069', bare numbers accepted), clarifies redact behavior ('pass redact=false'), and explains bundleId optionality. This adds clear value 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?
The description clearly states that the tool returns the full detail of one captured network request by event id. It specifies included content (headers, bodies) and references sibling tools find_errors and search_network, distinguishing itself effectively.
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 instructs to use event ids from find_errors or search_network, providing clear context for when to use this tool. However, it does not explicitly exclude alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries behavior disclosure burden. It notes the block is 'when present' and lists returned fields, implying safe read operation. Lacks explicit statement of side effects, but read nature is clear.
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 with zero wasted words: first sentence lists content, second sentence provides usage alternatives. Front-loaded with key purpose.
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 tool with one optional parameter and no output schema, description fully covers what the tool returns (listing fields) and when to use it. No gaps remain.
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% for the single parameter, so baseline is 3. Description does not add parameter details beyond schema, which is acceptable as schema already explains bundleId's purpose and optionality.
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 it returns the bundle's pre-computed semantics block, listing specific fields (stateAtCapture, errorSummary, etc.). Distinguishes from siblings by advising to use find_errors/get_* for detailed drill-down.
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 recommends using this tool for UAT triage orientation and directs to alternative tools (find_errors, get_*) for per-event analysis, providing clear when-to-use and when-not-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: never last action, default types, source auto logic with thresholds, explicit source options, response includes actionSource, and each action includes rrweb window. No annotations to contradict.
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?
Description is information-dense but front-loaded with main purpose. Every sentence adds value, though slightly dense for quick scanning.
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?
Comprehensive for a read tool: covers default behavior, all parameters, response structure, and integration with other tools (get_action_replay). No output schema needed as return values are described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by explaining default types, source auto decision logic, and clarifying that types exclude raw text inputs by default.
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 it returns the full user-action timeline, distinguishes from sibling tools like bundle_overview which gives last action, and mentions get_action_replay for replay windows.
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 guidance on when to use this tool (full timeline vs last action) and how to filter by types or source, but does not explicitly exclude other use cases or name alternative tools beyond last action reference.
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:

[![shadow-monitor-mcp MCP server](https://glama.ai/mcp/servers/yurii-mandzii/shadow-monitor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yurii-mandzii/shadow-monitor-mcp)

Score Badge

Copy to your README.md:

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

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