How AI agents reach your BSS through a CLI and MCP

A customer calls on a Tuesday afternoon and asks when their fibre will be switched on. The person at the service desk opens the customer record, then the order, then the feedback from the installation partner, and puts the answer together from three screens. An AI agent asked the same question has the same problem, without the screens. It needs a defined way into those systems.

This article is for the head of IT at an ISP, MVNO or reseller who has heard of MCP and wants to know what to do with it. It covers what a command-line interface gives an agent, what the Model Context Protocol is, how the two relate, what a sensible first integration looks like, and what to require from any vendor that offers either.

Why agents need defined access

Screens are built for people. An agent that clicks through a web interface breaks when a button moves, and it sees whatever the logged-in user happens to see. Programming interfaces give agents defined access to data and actions: each operation has a name, its inputs are described, its result has a fixed shape, and the system can check who is asking before it answers.

For an operator this matters for a practical reason. The question “where is this order?” touches the CRM, order management, provisioning feedback and sometimes billing. If each of those answers through a defined operation, an agent can combine them the way a good dispatcher does. If they only answer through screens, every agent project starts with screen scraping, and every release of every tool can break it.

What a CLI gives an agent

A command-line interface offers a fixed set of commands. An agent that can run commands on a computer calls them and reads the structured result. Take a hypothetical tool called bss and an order check:

$ bss order show 48213 --json
{
  "order": "48213",
  "customer": "C-10442",
  "product": "Fibre 1000",
  "state": "awaiting_installation",
  "appointment": "2026-11-04",
  "missing": ["ont_serial"]
}

The agent does not have to interpret a page. It gets the order state, the appointment and the one thing that blocks the activation, and it can explain that to a person in plain words or pass it to the next command.

A good CLI for agents has a few traits worth looking for. Every command can describe itself (inputs, whether it reads or changes something, which permission it needs), so the agent can look an operation up before it runs it. Data commands return JSON on request. Errors come back as clear messages with stable exit codes. Anything that changes or sends something offers a dry run that shows the request without executing it.

A CLI runs where the agent runs, usually on a staff member’s workstation, and acts with the credentials of whoever set it up. That makes it a good fit for people who already work with an agent at their desk, and for scripted checks that run on a schedule.

What MCP is

The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems such as data sources, tools and workflows (Model Context Protocol, 2026). It is supported by AI assistants such as Claude and ChatGPT and by development tools such as Visual Studio Code and Cursor.

The architecture has three participants. The host is the AI application. For each system it connects to, the host creates a client. The server is the program that exposes a system’s functions. A server can offer tools (functions the AI application can call), resources (data that gives context) and prompts (reusable templates). Messages use JSON-RPC 2.0. A local server talks to the client over standard input and output, a remote one over HTTP (MCP architecture overview).

For a back office the tools matter most. Each tool has a name, a description and a JSON Schema for its inputs, and it can declare an output schema so results come back as structured data. The client asks the server which tools exist (tools/list) and calls one with arguments (tools/call). The specification also states that servers must validate all tool inputs, implement access controls and rate limit tool calls, and that clients should ask the user to confirm sensitive operations and log tool use for audit (MCP specification, Tools).

How the two relate

A CLI and an MCP server are two ways into the same business functions. “Show order 48213” should be one operation in the business system, reachable as a command for agents that run commands and as an MCP tool for AI applications that connect over the protocol.

What matters is where the logic and the rights live. Neither the CLI nor the MCP server should contain business rules or decide on its own what a caller may do. Both pass the request to the business system, and that system checks identity, role and permission and returns the result. If a vendor’s MCP server has its own idea of who may see which customer, you now maintain two sets of rules, and they will drift.

In practice, many operators will start with the CLI because it is easy to test: you can run the same command by hand and see exactly what the agent sees. A remote MCP server becomes useful when several AI applications, or later your customers’ own assistants, need the same functions without installing anything.

A first integration in a telecom back office

Start with one recurring question that costs your team time every week, and keep the agent to reading. A good candidate is open relocations: the agent checks every relocation order, compares the order state with the technical feedback from the network team and lists what is missing (a confirmed date, an access code for the building, a new ONT serial) for customer service. Another is next week’s fibre activations with an open blocker.

The order of work matters, so here it is as steps:

1. Name the question and the person who owns the result. That person checks the list and decides what happens next.
2. List the read commands the agent needs: customer lookup, services of a customer, order status, provisioning feedback, open tickets. Grant nothing else.
3. Create a separate identity for the agent with a read-only role, so its requests are distinguishable from those of the staff member who runs it.
4. Run it next to the manual process for a few weeks and compare the agent’s list with what the team found.
5. Discuss write actions only after that, one at a time, each with an explicit confirmation by a person.

The agent reads, the person decides. That keeps mistakes cheap while you learn where the data is stale or where two systems disagree.

One more decision belongs at the start. The agent may send returned data to its AI provider. Decide which fields the read commands return (the dispatcher needs the address and the appointment, the agent does not need the customer’s bank details) and choose an agent and hosting setup that fits your data policy.

What to require from any vendor

Whether it is your BSS vendor, your CRM or a network management tool, ask for the following before you connect an agent.

Authentication. Every request carries an identity, for people and for agents. For remote MCP servers the authorization specification follows OAuth 2.1, and servers must check that an access token was issued for them (MCP specification, Authorization). Authorization is optional in the protocol, so ask whether it is switched on.

Scoped permissions. An agent gets the rights its task needs and no more. The MCP guidance recommends short-lived tokens and least-privilege scopes split per tool or capability, verified on the server for each call (Understanding Authorization in MCP). Ask how a read-only agent is set up, and what happens when it tries to write.

Logging. Each call leaves an entry: which agent, on whose behalf, which command, which records, when, and the result. Ask to see the entry for a refused request.

Rate limits. An agent stuck in a loop can call the order system far faster than any service desk. Limits per agent protect the system and show you when something is wrong.

Versioning. Commands and tool schemas change. MCP itself identifies protocol versions by date, and the current version is 2026-07-28 (MCP versioning). Ask how the vendor versions its own commands, how long a deprecated one keeps working and where changes are announced.

A useful test in any demo: ask the vendor to run a command the agent is not allowed to run, then show you the log entry it left.

The METAVSHN CLI and MCP server

We run an ISP ourselves (Ticinocom, where the founders have spent 30+ years in telecom), so we built these interfaces for the questions our own service desk asks. The METAVSHN CLI and MCP server are in early access.

The CLI runs on your machine and works with the agent your company already approved, any agent that can run commands. It looks up customers, services and policies. Searching for a command and describing it work offline, without a request to your BSS. Data commands return JSON, and each command contract lists its inputs, the type of operation and a permission hint. The MCP server exposes the same functions to AI applications that speak MCP.

Every request, from the CLI or the MCP server, is checked by METAVSHN against identity, role and permission. These permission hints tell the agent what an operation will likely need. They grant nothing by themselves. Deleting something or sending something out needs explicit confirmation, and a dry run shows the request before anything is sent.

If you want to try a first read-only integration on your own customer and order data, tell us which agent your team uses and we will add you to the early access group: the METAVSHN CLI and MCP server.

Sources

All sources accessed on 31 October 2026.

1. Model Context Protocol, “What is the Model Context Protocol (MCP)?”, documentation for protocol version 2026-07-28, July 2026. modelcontextprotocol.io
2. Model Context Protocol, “Architecture overview”, protocol version 2026-07-28, July 2026. modelcontextprotocol.io
3. Model Context Protocol, “Tools”, specification version 2026-07-28, July 2026. modelcontextprotocol.io
4. Model Context Protocol, “Authorization”, specification version 2026-07-28, July 2026. modelcontextprotocol.io
5. Model Context Protocol, “Understanding Authorization in MCP”, July 2026. modelcontextprotocol.io
6. Model Context Protocol, “Versioning”, current version 2026-07-28. modelcontextprotocol.io