Perceptdot
Server Details
B2A2H platform — tracks GA4, Vercel deployments, GitHub workflows with AI-powered ROI analytics.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2024-11-05
- URL
TDQS
Scored across 1 tool
With only one tool, there is no risk of confusion between tools. The tool's purpose is clearly defined and distinct.
Single tool naming is consistent by default. The name 'visual_check' is descriptive and follows a clear pattern.
While a single tool is on the low end, it is appropriate for a specialized visual testing server. The tool covers a focused use case without being overly minimal.
The tool captures screenshots and analyzes for visual bugs, covering the core functionality. However, additional tools for configuration, comparison baselines, or batch processing would make the surface more complete.
Available Tools
1 toolvisual_checkAInspect
Screenshot a URL and analyze it for visual bugs using AI. Returns whether issues exist, a summary, and a detailed issues list. Use this after deployments, PRs, or any UI change to catch layout problems.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to visually check (must be publicly accessible) | |
| prompt | No | Optional: specific aspect to focus on | |
| no_cache | No | Optional: bypass cache | |
| viewport | No | Optional: viewport size — desktop (1280px), tablet (768px), mobile (375px) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains the AI analysis and return structure but does not specify whether the tool is read-only, if screenshots are stored, or any authentication requirements. This leaves gaps for an agent to assess side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loading the core function and following with usage guidance. Every word adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema), the description adequately covers what the tool does and when to use it. However, it lacks details on behavioral aspects like caching or data retention, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond what the schema already provides. It does not elaborate on parameter defaults, constraints beyond the schema, or usage tips. The baseline of 3 is appropriate since the schema is already informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function ('Screenshot a URL and analyze it for visual bugs using AI') and the output format ('Returns whether issues exist, a summary, and a detailed issues list'). It uses a specific verb and resource combination that leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends usage after deployments, PRs, or UI changes, providing clear context. However, it does not discuss when not to use the tool or mention any alternatives, though no sibling tools are available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
visual_check
Related MCP Connectors
Privacy-first web analytics for AI agents: visitors, revenue, funnels, visitor profiles.
Read-only SaaS business intelligence from GA4, Stripe, and Google Search Console.
Analytics your AI agent can actually use. Track, experiment, and optimize via MCP.
AI marketing agent for Google Ads, Meta, GA4, TikTok, LinkedIn, Shopify, HubSpot and more.
Related MCP Servers
- AlicenseAqualityDmaintenancePrivacy friendly, cookieless web analytics built MCP-first. "Add analytics to my Next.js app" → an AI agent runs the setup_analytics_for_site tool, picks the right install snippet, edits your layout file, and verifies the script is loading. OAuth onboarding, no API keys to paste.2824 npm1MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI-powered analytics from Stripe, PayPal, and Google Analytics 4 (BigQuery) data sources with built-in guardrails and automated workflows for financial and web performance insights.-
- AlicenseNot gradedqualityDmaintenanceAutomates Google Analytics 4 and Google Tag Manager setup, management, and health monitoring with blueprints, multi-environment support, and MCP tools for AI agents.MIT
- AlicenseAqualityFmaintenanceEnables unified querying of GA4, Cloudflare Web Analytics, Vercel Analytics, and Google Search Console through a single MCP interface, with cross-tracker comparisons and discrepancy reporting.21MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.