An AI agent onboarded itself and called me

More of the work around a voice trunk is being handed to software that acts on its own: route testing scripts, procurement agents that shop for carriers, operations agents that open a case when quality drops. Every one of them hits the same wall we all built over the years: a portal, a confirmation e-mail, a sales call. If the only way into a product is a person clicking, an agent cannot be a customer, and a NOC cannot script the boring parts.

Open Voice Shield already had a REST API behind everything the portal shows. What it did not have was a way to place a call without a switch, a description of itself that software could read first, and a protocol that agent frameworks speak natively. Those three are what shipped.

Discovery files

/llms.txt says what the product is and is not. /.well-known/agent.json is an agent card in the A2A format with the endpoint, how to authenticate and the skills. /api/openapi.json is the full contract. An agent that lands on the origin needs no HTML.

An MCP server

/api/mcp speaks the Model Context Protocol over Streamable HTTP: JSON-RPC, one request per message, nothing to keep between them. Twenty tools wrap the common steps, from signup to get_transcript, each with a plain description and an input schema. A tool runs its REST endpoint in-process with the caller's own credentials, so there is one authorization path, one audit log and one rate limit whichever door you use. Two tools work without credentials: the guide and signup.

API test calls

POST /customer/test-calls asks the platform to place a call for you. It originates a SIP call from its own small user agent into its own ingress, routes it through your destination, plays a speech sample for the seconds you asked, and hangs up. The sample is a neutral announcement or a recording of a known scam script, for when you want to confirm a block verdict and an alert come back. The call is recorded, transcribed and analyzed like any other and appears with origin test.

Keys as bearer tokens

An API key is now accepted as Authorization: Bearer as well as X-API-Key, because most agent frameworks can only set a bearer header.

The agent was an off-the-shelf AI coding agent with an HTTP client, given the site address and told to go from nothing to a verdict. Everything below is from its log, trimmed to the fields that matter. Identifiers are shortened.

GET  /api/mcp                       20 tools · auth: Bearer <token or key>
initialize                          open-voice-shield · protocol 2025-06-18
get_started                         "the ordered steps from signup to a verdict"
signup                              customer d024… · balance 5.00
create_api_key                      ovs_bQQE… (shown once)
me                                  agent-…@example.com · Agent Co
add_destination                     carrier host:5060 udp · tech_prefix set · default
add_routing_rule                    962 -> that destination
set_webhook                         https://agent.example.com/ovs-hook (signed)
add_alert_rule                      "Block at 80" · min_probability 80
account_balance                     5.00 · pay-as-you-go
place_test_call                     my mobile · 30 s · route_test
get_test_call ×1                    done · answered false · 503 Service Unavailable

The first call never rang. The carrier refused it in under a second with a 503. The SIP trace on the call record showed the INVITE leaving correctly with the prefixed number. A call minutes earlier to a number in Jordan had gone through on the same route. The difference was the destination and the caller ID: the platform's default test caller ID is a placeholder, and that route screens caller IDs for North American destinations.

The agent read the trace, looked up a number the account owns, and retried with it as the caller ID.

place_test_call                     my mobile · caller_id 9627…9573 (owned) · 30 s
get_test_call ×6                    done · answered true · 200 OK · 20.8 s · ended by callee
get_call ×1                         completed · analysis done · PCMU · pdd 3.2 s · answered in 8.3 s
                                    probability 5 · robocall · allow · red_flags []
                                    est. MOS 4.4 caller / 4.4 callee · 0 % loss · jitter < 1.2 ms
get_transcript                      CALLER: This is an automated route test call from Open Voice Shield…
                                    CALLEE: All right, thank you.
report_links -> GET report.pdf      200 · 74 KB

My phone rang three seconds after the request, I answered eight seconds in, listened to the announcement, said thanks and hung up. Under a minute later the agent had the verdict, both sides of the transcript, the quality of each leg and a PDF report, all read through the same tools. The summary it got back called the call an automated route test with no personal information, pitch or pressure, which is what it was.

Route testing becomes a script. A NOC's own script, holding an API key, can dial every vendor route every morning with the neutral sample, read the post-dial delay, the answer delay, the estimated MOS per leg and any false answer supervision alert, and open a case on the ones that moved. An assistant working through the connector asks for each call instead, and a person confirms it in the portal before it rings. It needs no probes, dedicated test numbers or switch changes.

Vendor conversations start with evidence. The same agent can place the scam sample through a route and confirm that a block verdict and an alert arrive, or fetch the PDF report of a real call that went wrong and attach it to the ticket.

Agents can be customers. An agent that shops for a fraud analysis service can evaluate this one end to end, on its own carrier, and decide, with its person signing in on our page and confirming each test call. We think that is where procurement is going.

The guide is at /docs/agents: the full flow with curl, the MCP tools, and the guardrails. Or skip the reading and give your agent the server URL, https://ovs.telecomsxchange.com/api/mcp: at first use it signs you in, or it sends a key from the Developers page as a bearer header. The first tool it should call is get_started. It will know what to do from there, and it will hand you a link to confirm each test call.

One limit: a consumer chat assistant cannot connect itself to anything, and its page fetch is read-only, so it cannot connect by reading this post. One click does it instead: Add to Claude opens the connector dialog filled in, the first account tool opens our sign-in page, and from then on the assistant runs the same journey, with you confirming each test call. The guide has every client.