Natural language queries with LLMs via MCP servers

Dave Morris dave.morris at metagrid.co.uk
Wed Jul 29 16:53:50 CEST 2026


Short answer - Yes, I would be very interested in learning and sharing 
more about this, and pooling our experience sounds like a very good 
idea. The whole field is moving so fast it is hard to keep up.

AI agents are changing the way that scientists interact with our 
services. Rather than learning a command-line interface or a web 
application, I think LLMs and coding agents have the potential to become 
the natural-language interface to scientific data, which will have a big 
impact on the design of the next generation of tools and services.

---

There are several layers of things that we can do to help actors (human 
and AI) to use our services and MCP service descriptions play an 
important role.

Our own experience is that LLMs are **very** good at reading machine 
readable specifications like OpenAPI.

Given an OpenAPI description of a service, I have seen coding agents 
happily swap between command line curl commands, on-the-fly Python code, 
and client libraries, all within the same session, choosing whichever 
approach is most appropriate for the task.

Turns out a good test of how well you have designed your API is whether 
a coding agent will choose to use it, or just do their own thing. They 
have no qualms about ignoring your carefully crafted client API and 
reverting back to using curl or their own on-the-fly Python code if it 
gets the job done quicker.

But OpenAPI and MCP only cover part of the problem, they describe _how_ 
to use the service, not _why_ a scientist would want to use it .

As an experiment, I asked ChatGPT:
> What is the best format for explaining [how to use a data access 
> service]
> OpenAPI or Model Context Protocol ?
and
> Are there any other methods that we should consider ?

You can read the full answer here 
[https://chatgpt.com/share/6a69ac50-1650-83eb-8ed4-40bb299fc017]
but I think the last paragraph sums it up fairly well.

> The most important addition is not another transport protocol.
> It is a machine-readable semantic model plus tested task examples.
> OpenAPI tells an agent that a parameter is a number; the semantic model
> and examples tell it what that number means, which coordinate system it
> belongs to, which values are scientifically valid, and when to use it.

The IVAO is making good progress towards providing that semantic 
metadata, but what struck me with this is that our protocol standards 
describe how to build a service, and our metadata standards describe how 
to curate and annotate the data. But how much end-user documentation do 
we have that describes how to use them ?

OpenAPI and MCP clearly have a role to play, but they are only part of 
the solution. Do we also need more plain-language documentation, worked 
examples, tutorials and task-oriented guides showing how our services 
fit together in practice?

Something we have been experimenting with is writing plain text 
descriptions and examples of how to use our services and our Python 
client API that can be packaged as a SKILL that an AI agent can import 
and use.
https://agentskills.io/home

LLMs are really good at reading end user documentation and code 
examples, it is what they were trained on,
and more documentation helps both AI and human agents understand our 
services.

Cheers
-- Dave

--------
Dave Morris
Research Software Engineer
UK SKA Regional Centre
Department of Physics and Astronomy
University of Manchester
--------
AIMetrics: [
       {
       "name": "ChatGPT",
       "version": "GPT-5.5",
       "model": "GPT-5.5",
       "timestamp": "2026-07-29T06:57",
       "log": 
"https://chatgpt.com/share/6a69ac50-1650-83eb-8ed4-40bb299fc017"
       "contribution": {
         "value": 50,
         "units": "%"
         },
       }
     ]
--------


More information about the interop mailing list