Servidor MCP de SitePulsar

• Nombre en el registroai.sitepulsar/mcpverificado en el registro MCP

El nombre en el registro está bajo sitepulsar.ai. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-23
• Herramientas13
• El servidor se llamasitepulsar-mcp
• Versión del servidor0.0.1
• Versión del protocolo2025-11-25

El 2026-10-23 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 155 ms.

• Aún no se ha juzgado si sus herramientas hacen el trabajo del producto.
• Comprobado 1 de los 7 días necesarios para juzgar su fiabilidad.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCPtras una semanala nota necesita 7 comprobaciones diarias: 1 hasta ahora
• Respondiómidiendo1 de las 7 comprobaciones diarias necesarias para mostrar el porcentaje
• Mediana de la primera respuesta145 ms
• Espacio en el contexto del agente≈ 2450 tokenslas definiciones de todas sus herramientas (13), que el agente lleva en cada turno
• Definiciones de herramientasA · 100 de 100
• Resultados tipados13 de 13 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Todas las herramientas pasan las seis comprobaciones.

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (30%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%) y uso (15%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y números →

• check_agent_readiness

  Fast synchronous AEO / agent-readiness read of a single URL: robots and bot access, structured data (schema), and content structure. Returns immediate signals without running a full audit. Use this to triage a page or sanity-check before…

• run_audit

  Run a full AEO audit of a URL covering FIND, READ, and USE. Async: returns an audit_id to poll with get_audit. Accepts an optional target_keyword. Spends one audit credit per fresh run; a same-URL re-run within 24h reuses the cached…

• get_audit

  Fetch an audit's status and, when complete, a compact decision-ready SUMMARY: AEO score (overall + FIND/READ/USE), a short summary, the weakest pillar, headline takeaways, and the top fixes. Lead with this; call get_audit_detail only when…

• get_audit_detail

  Full structured per-section breakdown of a completed audit, on demand (only call after get_audit when you need depth): per-dimension FIND/READ/USE sub-scores, reputation across AI engines, competitor cluster (named for paid tiers)…

• compare_aeo

  Compare AEO posture across multiple URLs (e.g. a brand versus its competitors) on the same FIND/READ/USE pillar scale. Async: returns an audit_id to poll with get_audit. Spends credits only for freshly-audited URLs; recent audits are…

• get_fixes

  Return the prioritized, pillar-tagged (FIND / READ / USE) action plan for a completed audit, deduplicated across sources, with machine-actionable implementation steps included on fixes where available. Use this when you want the to-do…

• get_audit_full

  One call that returns a completed audit's SUMMARY, full per-section DETAIL, and deduplicated prioritized FIXES together — so you don't have to chain get_audit → get_audit_detail → get_fixes. Use `expand` to trim the payload ('summary' |…

• search_companies

  Samples the major AI engines for which companies they name for a query (e.g. "best CRM for startups"); returns a consensus shortlist (≤5). Use when you want to know who agents *recommend* for a category — not where a specific brand is…

• probe_agent_discovery

  Checks selected registries (official MCP registry, PyPI, GitHub) for packages/servers tied to a domain or brand. A discovery-surface check (can agents find your published tooling?), not a visibility check. Use when you want to know…

• probe_ucp_readiness

  Inspects /.well-known/ucp to report whether AI shopping agents can transact with the site (presence + advertised capabilities only — never a live purchase). Use when evaluating an e-commerce or merchant site for agentic-commerce…

• probe_mcp_functional

  Discovers a site's advertised MCP endpoint (mcp.json / .well-known) and inspects its *declared* OAuth/transport posture (advertised, not guaranteed-working — it does not run a full live handshake). Use when checking whether a site exposes…

• scan_product_page

  Deterministically scores one product page (schema, price, availability, image) 0–100 for shopping-agent readability — no LLM, fully repeatable. Use when you want a precise, single-page readability score for a specific product URL rather…

• scan_visibility

  Live AI-visibility scan for a brand: crawl + reputation sampled across AI engines, returning where *that* brand is mentioned (any public brand, not just your own). Use when you want to know whether and how a named brand already surfaces…