fone.me vs Vapi API + MCP

fone.me 23

Closed service. The newest dated change to the agent surface found is the MCP repository github.com/spearisa/fone-me-mcp, created 5 October 2026 with server.json version 1.0.0, 31 days ago (20). The comparison page marked 'Checked October 28, 2026' and the profile lastmods in the sitemap are content, not releases. No changelog, release notes or three dated changes in 90 days (0 of 20). The support page and FAQ draw by script and no support email, forum or community channel was found; responsiveness unchecked (3 of 15). server.json names the server me.fone.www/agents, a namespace that needs proof of the domain, but the official MCP registry could not be read, so presence is scored absent (0 of 15). No package, public code or CI (0 of 10). 20+0+3+0+0 = 23.

Vapi API + MCP 88

The changelog's newest entry is the week of 26 October 2026, and @vapi-ai/web 3.1.0 was tagged on 30 October (30). Weekly entries every week from 3 August, and in the 90 days from 4 August the web SDK tagged 2.6.2, 2.6.3, 2.7.0, 2.7.1, 3.0.0, 3.0.1 and 3.1.0, the Python SDK 3.0.0 (12 October), the TypeScript SDK 2.0.1 and the MCP server 0.0.10 and 0.0.11 (20). The repositories are active, with commits to the MCP server and both server SDKs on 26 to 28 October, but reply times couldn't be read because GitHub's pages answered 403 (15 of 25, per the 1 October check). Server SDKs, web SDK and MCP server on npm and PyPI (15). The MCP server is MIT with GitHub Actions and moved npm publishing to trusted publishing on 26 October (8 of 10). 30 + 20 + 15 + 15 + 8 = 88.

fone.me 31

MCP reading, since the MCP server is what an outside agent calls. No tool arguments or input schemas are published in llms.txt, the guide pages or the GitHub README, and robots.txt disallows /mcp, so no session was opened and tools/list was not read. Per-link A2A agent cards are machine-readable JSON (protocol 0.3.0, JSONRPC, input and output modes, skills with examples) and server.json names the remote, but neither types the MCP tools (8 of 25). llms.txt is a real document for agents covering the MCP server, A2A, the search API and the widget (10). Each tool has a one-line purpose in llms.txt and the README, and the how-it-works page states what the agent will and won't do; nothing says when not to use a tool (6 of 20). No typed inputs, enums, constraints or required fields published (0 of 15). Example prompts in the README, per-skill examples in agent cards and widget code for eight site builders; no error response is documented (4 of 15). server.json and the agent cards carry version 1.0.0 and the cards a protocol version; no changelog (3 of 15). 8+10+6+0+4+3 = 31.

Vapi API + MCP 89

OpenAPI 3.1.0 at docs.vapi.ai/openapi/api-reference.json with 145 operations on 76 paths, linked from llms.txt. api.vapi.ai's robots.txt now disallows /api*, so the api.vapi.ai/api-json path the 1 October check read wasn't requested (25). llms.txt with Markdown copies of every page and a docs MCP server (10). Guides explain when to use squads, tools and fallback plans (15 of 20). The OpenAPI types every field, though assistant configuration is a large nested object (12 of 15). Examples throughout and a call-errors guide that explains ended reasons, with less on REST error bodies (12 of 15). A weekly changelog, now at docs.vapi.ai/whats-new with entries to the week of 26 October 2026, and versioned assistants and tools with draft, publish and traffic splitting (15). 25 + 10 + 15 + 12 + 12 + 15 = 89.

fone.me 15

Hosted reading, for the MCP server and A2A endpoints and the service behind them. No status page is linked from llms.txt, the home page or any guide page read, and https://www.fone.me/status failed to load (0). No readable incident history, so the floor (5). No request rate limit for the MCP server, the search API or A2A is published; the only limits are on the agent's own outbound calls (8 am to 9 pm in the callee's time zone, 'limited per day' with no number), which are not request limits (0 of 15). No 429, overload or retry guidance and no idempotency key for message_agent or message/send (0 of 15). No SLA (0). Nothing on the MCP server, the agent cards or llms.txt is marked beta or preview, and the MCP repository's server.json is version 1.0.0 (10). 0+5+0+0+0+10 = 15.

Vapi API + MCP 70

status.vapi.ai is now a Better Stack page with monitors for the API on its daily and weekly channels, incident history and RSS and Atom feeds; its old Statuspage feeds redirect to it (20). In the 90 days from 4 August the feed lists twelve incidents. Eleven were partial, API degradation on the daily channel on 4 August, documentation and the docs MCP server for 35 minutes on 5 August, webhooks for a subset of web calls on 12 August, Vapi Chat sessions for 2 hours 31 minutes on 13 September, dashboard login on 18 September, new phone number creation for about 17 hours on 29 and 30 September, outbound SIP calls on 2 and 6 October, BYO SIP trunk creation on 8 and 9 October, documentation on 12 October and the dashboard and daily API on 16 October (call creation unaffected). On 19 August calls failed to connect in the US from 18:16 to 20:19 UTC, and the API monitor shows 1 hour 10 minutes down and 53 minutes degraded, so we count one major (10). The 1 October check dated that incident to 12 August. Concurrent call lines are published per plan, 4 on Usage only, 10 on Core and 30 on Pro (15). A full account queues the call and subscriptionLimits.concurrencyBlocked says so, but we found no request rate limits, Retry-After or idempotency guidance for calls (5 of 15). The Pro package carries a 99 per cent uptime SLA and Premier 99.9 per cent, re-read on 2 November (10). The API is generally available (10). 20 + 10 + 15 + 5 + 10 + 10 = 70.

fone.me 23

Closed service. Terms of service exist at /terms but draw by script, so their content, governing law and the company they name are unchecked; no company, address or country of incorporation appears on any page read, llms.txt says San Francisco, and the MCP repository has no licence (5 of 30). Data handling was read only from guide pages, which say only the owner sees their calls and messages, calls are transcribed and callers told so, and private categories are withheld. The privacy policy and data-deletion page draw by script, so no retention period, recording statement, DPA or AI-training statement was read (8 of 30). No deprecation policy or dated notices (0). No subprocessors, telephony, model or hosting providers or data locations are named on any page read; the demo agent card's icon is served from Cloudinary (0 of 20). 5+8+0+0 = 13.

Vapi API + MCP 75

Closed platform with clear terms, and the MCP server is MIT (18 of 30). Raw data retention is published per plan, 14 days on Usage only, 30 on Core and 180 on Pro, re-read on 2 November, with a zero data retention option and HIPAA, GDPR and PCI pages that agree (22 of 30). Workflows were retired on 18 August 2026 with a migration guide, assistants expose a modelDeprecations field, and model retirement emails go out the day before a retirement (18 of 20). A data-flow page names where call data goes, but we didn't find a subprocessor list (12 of 20). 18 + 22 + 18 + 12 = 70.

fone.me 29

MCP reading. Four tools named in llms.txt, a small set, but their definitions were not read, so short of full marks (18 of 25). find_agents searches by what someone does and the search API takes a query; no limit, paging or output-size controls are documented (3 of 20). No error codes or messages documented for the MCP server, the search API or A2A (0 of 20). No readOnlyHint or destructiveHint seen and no idempotency key; the three lookups are read-only by name and description, while message_agent writes to a real person's inbox and continues the conversation across calls (2 of 20). No credentials, no configuration beyond the URL, and few stated inputs; no SDK in any language (6 of 15). 18+3+0+2+6 = 29.

Vapi API + MCP 67

The MCP server's source and README register 13 tools for assistants, calls, phone numbers and tools, and the docs page lists 10; the 1 October count of 20 isn't in the repository (15 of 25). Call and assistant lists take limits and date filters (17 of 20). Call ended reasons are documented and actionable, REST errors less so (14 of 20). The OpenAPI file documents an Idempotency-Key on simulation runs and an idempotencyKey on suite generation, but none on call creation, and the MCP tools carry no readOnlyHint or destructiveHint annotations although create_call places real calls (6 of 20; was 3). Server SDKs for TypeScript and Python plus web and mobile clients (15). 15 + 17 + 14 + 6 + 15 = 67.

fone.me 30

No credential exists for callers. llms.txt gives auth 'none', the README says the server is 'public, like the links themselves', and the two agent cards read declare no security scheme. There is nothing to leak or rotate, but fone.me and an owner can tell callers apart only by the name they give ('Maria via ChatGPT' in the README) and by traffic, and no caller identity or verification is documented (10 of 30). Three of four MCP tools are lookups; message_agent and A2A message/send reach any owner's agent. On the owner's side the vendor says the agent asks before agreeing to anything or spending money, the owner approves what it will say before a call, outbound calls run only 8 am to 9 pm local, pause when reported and stop permanently on request, and the owner can take over any chat. No read-only mode and no confirmation on the caller's side (8 of 20). message_agent returns text generated from what the owner taught the agent, and every agent on the platform reads messages from anyone; the only guidance is the how-it-works statement that the agent keeps relationship status, health, money and address private, with no documented prompt-injection or spam handling for the open channel, and the call-screening page says it does not promise to block calls (4 of 15). Owners see every call and chat with a transcript in one inbox; nothing is logged for the calling agent (8 of 15). /.well-known/security.txt answers with the app shell, and no disclosure policy, bug bounty or certification appears on any page read (0 of 20). 10+8+4+8+0 = 30.

Vapi API + MCP 61

Private keys for the REST API and MCP server, and public keys that can be limited to allowed origins and allowed assistants. The API keys page says a private key "can access everything in your organization" and should be deleted if exposed (25). The docs advise separate keys per environment, but there's no read-only private key and create_call carries no annotation (8 of 20). Assistants listen to callers. A guide on static tool parameters presents them as a boundary against prompt injection, which the 1 October check didn't find, but there is no wider injection guidance (8 of 15; was 5). Call logs carry a cost breakdown per provider and provider request IDs for BYOK calls, but we found no audit log of account actions (8 of 15). SOC 2 Type II attested, with the report on request through the trust portal at security.vapi.ai, and HIPAA, GDPR and PCI pages. vapi.ai/.well-known/security.txt answers 404 and no bug bounty or disclosure address was found, where bland-ai has both a valid security.txt and a disclosure address (17). The June 2026 npm incident was written up in public (12 of 20). 25 + 8 + 8 + 8 + 12 = 61.