Grok 4.5 vs Claude Fable 5: Seconds vs Minutes on a Live Telecom Exchange

You type one sentence into a terminal:

Compare voice pricing for destination Country A between Carrier X and Carrier Y (premium tier). Factor route type, capacity, and ASR/ACD. Then show my buyer balances.

Grok spins up the TCXC MCP server locally, hits the live TelecomsXchange wholesale API, and returns a rate table, capacity notes, quality signals, and a multi-account balance rollup. No portal. No CSV dump-and-filter. No waiting for someone to check the deck.

That is not a demo chatbot. That is wholesale telecom infrastructure driven by natural language, with an AI agent as the control plane. This post is the field guide: what the stack looks like, what we measured when two different frontier agents ran the same jobs on it, and the exact steps to configure it yourself.

A note on the examples: carriers, destinations, rates, and account identifiers below are anonymized. Real wholesale prices and supplier names are omitted on purpose.

Most MCP demos read a repo. This one moves live traffic.

Most Model Context Protocol demos are filesystem toys, GitHub wrappers, or generic SaaS glue. The TCXC MCP Server is different: it puts 59 production tools from a live wholesale telecom exchange, buyer side and seller side, in front of any MCP-capable agent. Rate intelligence, balances, CDRs, interconnects, routing groups, route tests, HLR lookups, DID inventory, and eSIM purchase flows, all reachable in plain language.

Telecom is a hard vertical for agents in exactly the ways that make it a good one: real money, real-time state, capacity constraints, adversarial fraud, and multi-party markets. An agent that works here is not answering questions about the network. It is working the exchange.

Measured: time to done on the same jobs

The server is model-agnostic. Grok, Claude, and any other MCP client all drive the same tools against the same live exchange, and both agents we tested completed the same wholesale jobs correctly. So the comparison that matters on an operations desk is not data quality. It is time to finished work: how fast the operator gets a usable answer or a shipped config.

We measured both sides with real wall-clock numbers on the same production-style buyer account (identity redacted):

How we measured

• Claude Fable 5 high: full agent session wall time as reported by the Claude UI ("Worked for 2m 4s", "Baked for 6m 2s"), which includes deliberation, tool calls, and writeup.
• Grok 4.5 high: instrumented wall clock on the same MCP client paths Grok uses (buyer balance, market search, routing-group list) plus the rank-and-format analysis, timed on a developer machine.
• Same effort tier: both agents ran at their high reasoning-effort setting, so neither side was handicapped on deliberation depth.

An honest footnote: a full Grok chat turn still adds model generation time on top of the instrumented tool-chain numbers, typically a few seconds for a balance table and more for a long writeup. That does not close a multi-minute gap. The multi-minute cost on the Fable side is orchestration and deliberation tempo, not a slow exchange API. A full destination market payload alone can take tens of seconds of pure API transfer, and Grok completed the shortlist and group confirmation inside that envelope.

Job A: buyer balances

Done means: pull all sub-accounts, surface funded balances, and flag blocked, negative, and shared-balance risk, without publishing real balances or account names. The Grok path is one MCP balance call followed by a structured desk table. Median across three runs: about one second.

Job B: destination LCR under a price cap

Done means: scan a country destination, filter under a user-set maximum price per minute, prefer high-quality CLI routes, and build or confirm an LCR routing group with a dialable tech prefix. The outcome shape, with carriers and rates anonymized:

The live result, structure only: an LCR group with three purchased connections, automatic failover hunt-stop codes, and a dialable tech prefix. Specific connection IDs, supplier logins, and per-minute rates are omitted for sharing. Grok re-ran the scan, rank, and confirm path in about 33 seconds; the Fable session needed about six minutes to reach a shipped group. Same job class, different tempo.

Job C: route tests are physics-bound

Multi-round route tests, with several probe calls and long ring waits, are partly bound by network ring and answer time. No agent can skip a long no-answer. Where agents still differ is setup, retest planning, and the CDR readback cycle between waits: tight loops around each probe rather than serialized long waits. Nobody is inventing faster SIP.

Why speed to done is the product

On a wholesale desk, rates move during the day, capacity and blocks flip, and live traffic and fraud need a pulse now, not in six minutes. A shortlist that took six minutes to assemble can already be stale, and a shift is many prompts in a row, so delays compound. If two agents can both finish the job, the faster one is the product. That is also the design bet behind the TCXC MCP server: the exchange side answers fast enough that the agent is the bottleneck, whichever agent you choose.

What you can actually do with it

1. Real-time rate desk

Compare voice pricing for Country A between Carrier X and Carrier Y (premium tier).
Include route type, capacity, effective dates, and any ASR/ACD.
Do not paste raw rate decks into external chats.

The agent returns side-by-side prefixes, flags who is cheaper, and notes quality signals where the exchange has traffic stats, for example one supplier showing recent ASR/ACD while another posts a price with no recent minutes behind it. That is a carrier routing conversation that used to take a spreadsheet and three logins.

2. Account health in one shot

Show buyer balances. Flag negative, blocked, and shared-balance (use_balance) accounts.

Multi-account hierarchy, credit limits, and parent balances, structured for a human deciding whether to top up or unblock. Balances are commercial data; share screenshots carefully.

3. Live network pulse

Show live buyer calls for a destination prefix. Summarize by vendor and duration risk.

4. Quality and fraud tooling

HLR lookup + number score on this CLD. Is it safe to terminate?

5. eSIM marketplace ops

Find eSIM packages for a target country under a budget cap. List what I already own.

6. Seller-side revenue view

Seller summary report for the last 7 days, group by customer and prefix.

Same agent, buyer and seller APIs, one session. That last part matters: the full marketplace loop, sourcing routes and selling routes, lives in a single conversation.

59 tools, one mental model

These are the exact tool names the server registers, straight from the source, grouped by what they do on the desk. Expand a domain to see its full surface.

The operating rule that keeps this safe: read freely, confirm before you spend. Market search, balances, CDRs, live calls, and routing-group listings are free reads. Interconnects, route tests, HLR lookups (often billable), DID and eSIM purchases, and account edits are commercial actions, and creating a routing group, changing its entries, or blocking a connection redirects live traffic. All of those should stay behind an explicit confirmation.

Configure it yourself

Prerequisites: Python 3.10+, a TelecomsXchange account with buyer and seller API keys (the server requires both to start), an authenticated Grok CLI, and Git.

Step 1: install the TCXC MCP server

git clone https://github.com/TelecomsXChangeAPi/tcxc-mcp-server.git
cd tcxc-mcp-server

python3 -m venv venv
source venv/bin/activate          # Windows: venv\Scripts\activate
pip install -r requirements.txt
cp .env.example .env
chmod +x start_mcp_server.sh

The launcher script loads secrets from .env, validates the TCXC_* variables, and starts the process Grok will spawn over stdio.

Step 2: credentials, local only

TCXC_USERNAME=your_buyer_username
TCXC_API_KEY=your_buyer_api_key

TCXC_SELLER_USERNAME=your_seller_username
TCXC_SELLER_API_KEY=your_seller_api_key

TCXC_API_BASE_URL=https://apiv2.telecomsxchange.com

Keys come from the member portal under Account, then API Settings. Lock the file down and never commit it:

chmod 600 .env

Step 3: wire Grok with one command

grok mcp add tcxc-mcp-server -- /absolute/path/to/tcxc-mcp-server/start_mcp_server.sh

This writes the server entry into ~/.grok/config.toml:

[mcp_servers.tcxc-mcp-server]
command = "/absolute/path/to/tcxc-mcp-server/start_mcp_server.sh"
args = []
enabled = true

Use the shell wrapper rather than a raw Python command so API keys never land in Grok's config. Absolute path, executable bit set. Grok can also import existing Claude MCP configs, but a native entry keeps the setup self-contained. For teams, --scope project writes a shared .grok/config.toml into the repo.

Step 4: prove it

grok mcp list
grok mcp doctor tcxc-mcp-server

Healthy output looks like this:

tcxc-mcp-server (stdio: .../start_mcp_server.sh)
  ✓ command found
  ✓ server started
  ✓ handshake OK
  ✓ 59 tools discovered

Found 1 healthy, 0 failing.

Inside a session, /mcps should list tcxc-mcp-server with about 59 tools; press r to refresh after edits.

Step 5: run the showcase prompts

Start grok and paste these in order. They tell a story: money, market, live traffic.

# 1. Money
Show my TCXC buyer account balances. Flag blocked, negative, and parent/shared-balance accounts.

# 2. Market intelligence
Compare Country A voice rates for Carrier X vs Carrier Y (standard and premium tiers).
Table: prefix, relative rate rank, route type, capacity, ASR/ACD if available.
Who wins on price under my quality constraints?

# 3. Live ops
Any live buyer calls right now? Summarize by destination prefix and vendor.

# 4. Optional stretch (confirm if billable)
Search CLI routes for Country B mobile. Shortlist top 3 by price with quality notes.
Do not interconnect unless I confirm.

Watch the loop: tool discovery, MCP calls, structured tables. That loop is the product.

Habits that keep it desk-ready

1. Specific prompts. Prefix, route type, and seller filters mean fewer tool retries.
2. Tight CDR windows. Large history pulls get truncated; ask for "last 6 hours, show=bad".
3. Deck filters in language. "From this tariff, only prefixes starting with the country code."
4. Confirm spend. Interconnect, purchase, route test, and HLR stay intentional.
5. Logs when debugging. ~/.grok/logs/mcp/tcxc-mcp-server.stderr.log has the server's side of the story.
6. Redact before sharing. Supplier names, per-minute rates, balances, and tech prefixes stay out of screenshots.

Troubleshooting, fast path

Security notes worth forwarding

1. Keys live only in the MCP server's .env, chmod 600.
2. Never paste API keys into chat.
3. Use separate staging keys where possible.
4. Treat purchase, interconnect, and test-call tools as production actions.
5. Point the config at an absolute path to a controlled server install.
6. Restrict who can read ~/.grok/logs/mcp/ on shared machines.
7. Before posting screenshots or docs, strip supplier names, live rates, balances, and account IDs.

An agent on a live exchange is powerful because it can act. Guardrails are what make that power shippable.

One exchange, any agent

Three things this stack demonstrates at once. MCP is the right abstraction for industry systems with dozens of operational verbs. Agent tempo is now a real differentiator: measured on the same TCXC stack, the same jobs finished in about one second versus 2 minutes 4 seconds, and about 33 seconds versus 6 minutes 2 seconds. And telecom is a strong vertical for agentic products, because money, real-time state, fraud, and multi-party markets punish slow loops.

The TCXC MCP server is open source on GitHub, and it speaks to any MCP client: Grok as shown here, Claude on the routing desk, or your own agent harness. Read more about the TCXC MCP Server and the wholesale platform, or the Model Context Protocol itself. To run it against your own traffic, talk to the team.

TelecomsXchange, the AI native interconnect.