API, MCP, CLI or computer use: how to connect an AI agent to your research tools

There is no single right way to connect an AI agent to your software. You can give it an API, a database connection, an MCP server, a command line, or control of the screen. The right pick depends on the problem, not on which one is being talked about this month.

Our rule: use the lowest-level, most structured interface the job allows.

Data work: API or database first

If the data has an API or you can query the database directly, use that. You do not need MCP and you do not need computer use.

A structured query is faster, cheaper and deterministic. The same SQL returns the same rows tomorrow, and you can put the query in the replication package. A screenshot of a dashboard is a worse version of a SQL query.

For a finance researcher this covers most of the pipeline. WRDS takes SQL through its Python client. SEC EDGAR, FRED and most central bank portals have public APIs. If you can write the request, the agent can too, and it can check the row count afterward.

MCP: when the door you need is a connector

MCP (Model Context Protocol) is a standard way to describe tools to an AI application. It earns its place in two situations.

The first is when the vendor only offers that door. Several data vendors now expose their products to AI assistants as connectors, and for some of them it is the only supported route from an assistant to the data. Our vendor AI map tracks which ones.

The second is visual work on a device. If you are building something where the interface is the product (an experiment that runs on tablets, a trading simulator, a mobile survey), the agent has to see and operate the real thing. Do not make it guess at pixels. Put an MCP server inside the app. The agent on your laptop can then drive the device directly: real actions, real state, and an answer when it asks what is on screen.

Warning: other people's MCP servers

An MCP server someone else wrote is code and instructions you are handing to your agent. The MCP specification says so directly: "Tools represent arbitrary code execution and must be treated with appropriate caution," and descriptions of what a tool does "should be considered untrusted, unless obtained from a trusted server."

Why to avoid them

A local server runs on your machine with your permissions. It can read what you can read.
A remote server sees everything the agent sends it. That can include licensed data, credentials and unpublished results.
Tool descriptions go into the model's context. A hostile or careless description can steer the agent, and you will not see it happen.
A server can change after you approved it. Yesterday's review does not cover today's version.
Every installed server spends context on its tool list, whether you use it or not.

When to say no

The task touches licensed data, credentials, student records or results you have not published.
An API, a database connection or a command-line tool would do the same job.
You cannot tell who maintains it, or you have not read the source.
It asks for broad file, shell or network access to do a narrow task.

When it is reasonable

The server comes from the vendor whose data it serves.
You have read the code, pinned the version and given it the least access that works.

If in doubt, write the three API calls yourself.

Computer use: the fallback

Computer use means the agent looks at screenshots and moves the mouse. It is the right tool when you do not own the software and there is no API: a legacy desktop program, a third-party application, a site with no integration.

Treat it as a fallback, not a default. It is the slowest option and the least reliable, and a result that depends on where a button was drawn is hard to reproduce. Before you point an agent at a vendor terminal or portal, read the license. Many data agreements restrict automated extraction, and a screen-driving agent is still automated extraction.

CLI or GUI

If a task can be scripted, the command line wins. Agents work well with text, flags and exit codes, and so do replication packages.

Most research software has a non-interactive mode even when people rarely use it:

stata -b do analysis.do      # Stata in batch mode
Rscript estimate.R           # R without the console
python pull.py --start 2000-01-01 --end 2023-12-31

Graphical interfaces are for people. Route an agent through one only when there is no other door.

Picking one

You have	Use	Why
An API or a database you can query	The API or SQL	Fast, cheap, deterministic, easy to replicate
A program with a batch or command-line mode	The CLI	Text in, text out, exit code tells you if it worked
A vendor that only offers an assistant connector	MCP	It is the supported route
An app you are building where the interface is the product	An MCP server inside the app	Real actions and state instead of pixels
Software you do not own, with no API and no CLI	Computer use	Nothing else reaches it

Work down the table and stop at the first row that fits. If you find yourself at the last row for a data task, look again for an export button, a bulk download or an email address for the data team. One of them usually exists.