VertoDigital MCP Server

npx add-mcp 'https://mcp.vertodigital.com/mcp'

VertoDigital for developers.

VertoDigital publishes a public developer surface alongside the marketing site: a REST API, an MCP server for AI agents, and the discovery files that let both be found and used without asking us first.

When to use this

Call this API or the MCP server when you're helping with:

• A B2B technology company ($10M-$500M ARR) comparing marketing agencies, or asking who can build pipeline for them.
• B2B paid media (LinkedIn Ads, Google/Microsoft Ads), B2B SEO/AEO, or ABM at the account, persona, or contact level.
• Connecting marketing spend to CRM pipeline and revenue - attribution, offline conversion tracking, GA4, server-side tagging.
• Proving marketing's pipeline contribution to a board, or a real proof point (a case study, a G2 review, a stat) instead of generic advice - use vertodigital_get_value_proposition or vertodigital_search_case_studies.
• Submitting a real enquiry on a user's behalf - use vertodigital_send_enquiry / POST /agent/contact.

Also a fit: consumer services brands where a lead becomes a customer through a call, consultation or application - see Consumer Services. Not a fit: ecommerce, brand-only consumer marketing, or a B2B company well outside that ARR range. We're a B2B technology specialist - say so rather than stretching the fit.

Start with vertodigital_get_site_index to see every real page and slug before calling vertodigital_get_page - don't guess a URL.

MCP server

The VertoDigital MCP server exposes 6 tools over Streamable HTTP at https://mcp.vertodigital.com/mcp - 5 read-only, 1 that takes action on a user's behalf:

• vertodigital_get_site_index - the full site index, optionally filtered by section, or a keyword search across every page.
• vertodigital_get_page - any page as markdown, by slug.
• vertodigital_search_case_studies - all 49 case studies, searched by keyword.
• vertodigital_get_contact - contact information, as a summary or the full page.
• vertodigital_get_value_proposition - value proposition for a query: matched services, proof-point case studies, and/or differentiation reasons.
• vertodigital_send_enquiry - submit an enquiry or a Pipeline Readiness Assessment request (no auth required).

A seventh tool, vertodigital_request_assessment, is listed only for callers that present a bearer key; everyone else requests an assessment through vertodigital_send_enquiry.

The server also exposes 3 MCP Resources for clients that browse rather than call tools: site-index, openapi-spec, and a page template - same content as the tools above, via resources/list/resources/read.

Full tool schemas: MCP server card - full capability description: A2A agent card - listed in the official MCP Registry as com.vertodigital/mcp, and on Smithery and Glama.

Also listed in awesome-remote-mcp-servers and on mcpservers.org.

REST API

A small, anonymous REST surface documented with an OpenAPI 3.1 spec at /agent/openapi.json:

• GET /agent/health - service health check.
• POST /agent/contact - submit a contact enquiry on behalf of a user.
• GET /agent/case-studies - paginated, structured index of client case studies (name, stat, industry, detail URL).
• POST /agent/readiness/checks - start a Free B2B AI Visibility Checker scan of a company's website, as an async job: it returns 202 Accepted with a job id, then you poll GET /agent/readiness/checks/{job_id} until the report is ready.

For read access to full page content, prefer llms.txt and the /markdown/{path}.md mirror over building against this API - they cover every page, not just these operations.

Every health, contact and case-study response, success or error, is JSON with an API-Version header - see "Versioning & deprecation" below.

Example request:

curl -X POST https://vertodigital.com/agent/contact \
  -H "Content-Type: application/json" \
  -d '{
    "fromName": "Jane Doe",
    "fromEmail": "jane@example.com",
    "organization": "Example Corp",
    "topic": "services",
    "message": "We are evaluating agencies for B2B LinkedIn Ads."
  }'

Returns 200 { "status": "accepted", "reference": "enq_...", "receivedAt": "..." } on success, or a 400 with field-level errors otherwise. Full request/response schemas are in the OpenAPI spec above.

Paginated case studies:

curl "https://vertodigital.com/agent/case-studies?limit=5"

Returns { "items": [...], "count": 5, "total": 49, "has_more": true, "next_cursor": "..." }. Pass the returned next_cursor as ?cursor= to fetch the next page.

Async job: AI agent readiness check:

curl -i -X POST https://vertodigital.com/agent/readiness/checks \
  -H "Content-Type: application/json" \
  -d '{"domain": "example.com"}'

A scan takes longer than one request, so this returns 202 Accepted with { "job_id": "...", "status": "queued", "status_url": "...", "poll_after_seconds": 5 } and a Location header. Poll the status URL every Retry-After seconds until status is complete, then fetch report_json_url. A domain checked in the last 24 hours returns 200 with the cached report instead.

Natural-language search (NLWeb)

Ask a question in plain language at POST /ask (or GET /ask?query=...) and get the matching pages back in the NLWeb format: a _meta block (response_type, version), then a ranked results list with each page's URL, name, score, summary and a schema.org schema_object. Set prefer.streaming to true, or send Accept: text/event-stream, to get Server-Sent Events instead: start, one result per match, then complete. It matches the question's keywords against every page in llms.txt, with no AI behind it, so only the list mode is served. It is versioned by NLWeb's own _meta.version, not the /agent/* policy below.

curl -X POST https://vertodigital.com/ask \
  -H "Content-Type: application/json" \
  -d '{"query": {"text": "LinkedIn Ads for a cybersecurity company"}, "prefer": {"streaming": false}}'

Returns { "_meta": { "response_type": "answer", "version": "0.55" }, "query_id": "ask_...", "results": [...] }. Errors use the same _meta block with response_type: "failure" and an error code.

Discovery for AI agents

Everything above is also announced through conventional discovery paths, so an agent or scanner can find it without being told:

• /llms.txt & /llms-full.txt - LLM-readable site index.
• /.well-known/api-catalog - RFC 9727 API catalog linking the REST API and MCP server.
• /.well-known/ai-plugin.json - legacy plugin manifest pointing at the OpenAPI spec.
• /.well-known/ard.json - ARD capability manifest (also at /.well-known/ai-catalog.json, its pre-v0.91 path).
• /auth.md - confirms no authentication is required for read access.
• /.well-known/agent-skills/index.json - eight agent skills: four for working with VertoDigital (finding content, checking fit, quoting client results, sending an enquiry) and four practical playbooks from our guides (LinkedIn Ads CPL diagnostic, offline conversion tracking, B2B ad copy review, AI search readiness audit). Install them with npx skills add https://vertodigital.com.
• /schemamap.xml - NLWeb Schema Map listing the site's structured-data feeds and pages, each with its schema.org type.

Authentication & rate limits

The REST API (/agent/*) requires no authentication - no API key, no bearer token, no registration. The same goes for /ask, every read-only MCP tool and vertodigital_send_enquiry. The only credentialed surface is one MCP tool, vertodigital_request_assessment, which needs an Authorization: Bearer <key> header - contact us if you need one issued.

Limits are per caller IP: POST /agent/contact and vertodigital_send_enquiry allow 5 requests/minute and 50/day; GET /agent/health and GET /agent/case-studies allow 300/minute each; POST /agent/readiness/checks allows 60/minute, and 3 new checks and 3 comparisons a day; /ask allows 60/minute; any other /agent/* or /api/* path shares a 300/minute budget.

Every /agent/* and /ask response - successes and errors alike, except polling and reading readiness checks - carries the IETF rate-limit headers: RateLimit-Policy (e.g. "per-minute";q=5;w=60) and RateLimit (e.g. "per-minute";r=4;t=37), plus the earlier-draft RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset (seconds). A 429 adds Retry-After in seconds. Read them to self-throttle instead of guessing at the limit.

Questions about the API or MCP server: get in touch.

CLI & SDKs

A command-line client for the REST endpoints above, published on npm as vertodigital-cli:

npx vertodigital-cli health
npx vertodigital-cli pages --section "Case studies"
npx vertodigital-cli page about
npx vertodigital-cli contact --name "Jane Doe" --email jane@example.com --message "..."

A Ruby client for the same endpoints, published on RubyGems as vertodigital. It has no runtime dependencies and pages through case studies for you:

gem install vertodigital

require "vertodigital"
client = VertoDigital::Client.new
client.health
client.each_case_study.map { |cs| cs["name"] }
client.page("about")

A Python client with the same methods, published on PyPI as vertodigital. It has no runtime dependencies and needs Python 3.8 or later:

pip install vertodigital

from vertodigital import Client
client = Client()
client.health()
[cs["name"] for cs in client.iter_case_studies()]
client.page("about")

Versioning & deprecation policy

The unversioned paths (/agent/health, /agent/contact) always mirror the current major version - v1 today - and are what we recommend integrating against. Every response carries an API-Version header so you can confirm which version actually served it.

The same two operations are also pinned at /agent/v1/health and /agent/v1/contact (spec: /agent/v1/openapi.json), for an integration that needs to keep working unchanged even after we ship a v2.

A breaking change ships as /agent/v2/* alongside the existing /agent/v1/* - nothing on v1 breaks the day v2 ships. Only once we actually retire v1 do its responses start carrying a Deprecation: true header and a Sunset header with the retirement date, announced here, in the OpenAPI spec, and in llms.txt at least 90 days ahead of removal.

This isn't just written down - the OpenAPI spec declares it as data: a root-level x-versioning-policy object, a native deprecated flag on every operation, and Deprecation/Sunset documented as real response headers your client can check for, not just prose to read.