<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi all,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">As André said, we have been
experimenting with LLMs in order to query CDS<br>
services in natural languages.</div>
<div class="moz-cite-prefix">The two main limitations at present (in
my opinion) are the following :</div>
<div class="moz-cite-prefix"><br>
1. LLMs want to please the user, and therefore will rather
hallucinate some<br>
plausible answer, rather than admitting they don't know how to
answer. This<br>
is quite frustrating. You can try to play with parameters and
reduce temperature,<br>
but I've seen too many behaviours where you can not trust the
answers.<br>
Examples include :<br>
- LLM invents some VizieR catalogue identifier, with an author and
bibcode, reference<br>
paper in A&A, with table and column names, to "retrieve"
information. All made-up.<br>
</div>
<div class="moz-cite-prefix">- Translation from natural language to
TAP query provides some ADQL and astroquery<br>
code. Everything looks nice, except some table names and columns
are complete<br>
inventions, and do not exist in the TAP schema.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">2. Turning a prototype into an
operational service requires serious computing<br>
resources, or a potentially very high cost in tokens used if you
rely on a third-party<br>
infrastructure. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">So far, we have had some interesting
results with MCP. I'd like to try testing skills<br>
in the near future to see if this can help improve reliability and
performance.<br>
There are already collections of astronomy-related skills in this
list of resources :<br>
</div>
<div class="moz-cite-prefix"><a class="moz-txt-link-freetext" href="https://www.skills.sh/">https://www.skills.sh/</a><br>
(including some for ESO services :
<a class="moz-txt-link-freetext" href="https://github.com/szampier/skills">https://github.com/szampier/skills</a> )</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Sébastien<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Le 29/07/2026 à 13:00, Schaaff Andre
via interop a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:1dde1386-1eaa-497c-959c-daa5686d0309@astro.unistra.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hello Tim and all</p>
<p>At CDS we (Thomas Boch, Sébastien Derrière and myself) worked
on a MCP server implementation and configuration in the frame of
the R&D around chatbots and AI for astronomical services and
tools. </p>
<p> Even if it was continued since Görlitz, Thomas had a talk in
the joint DCP/KD Session in November 2025 to give an overview of
the ongoing effort in this frame</p>
<p><a class="moz-txt-link-freetext"
href="https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpNov2025DCPKD"
moz-do-not-send="true">https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpNov2025DCPKD</a></p>
<p>we will be happy to join discussions and other actions </p>
<p>regards</p>
<p>André</p>
<div class="moz-cite-prefix">Le 27/07/2026 à 17:09, Tim Jenness
via interop a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAJcbMhm+C4J8AiS9GTUetW3yzdf+4SySLg4ReNR8K47wTVd5fA@mail.gmail.com">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<div dir="ltr">At the recent SPIE meeting in Copenhagen, Ashley
Barnes from ESO gave a talk on their experiments with teaching
an LLM to query their data archive. They looked at making a
dedicated agent taught explicitly but this cost them real
money, and they looked at writing markdown instructions that
the LLM could read to learn about the specifics of the archive
center. This led me to ponder whether we should be talking
about some kind of standardized MCP server interface (<font
color="#419cff"><span
style="-webkit-text-fill-color: rgb(65, 156, 255) !important;"><a
href="https://modelcontextprotocol.io/docs/getting-started/intro"
moz-do-not-send="true" class="moz-txt-link-freetext">https://modelcontextprotocol.io/docs/getting-started/intro</a></span></font>)
that an LLM could query to work things out about the archive.
<div><br>
</div>
<div dir="ltr">This seems to be the way that many services are
heading (my photos application has an MCP server to let an
LLM look for photos efficiently). On the one hand we have
all these open protocols so that in theory an LLM can work
it all out and form the right query for a TAP server by
querying registry and looking at TAP_SCHEMA, and that should
work. MCP <i>might</i> be able to let an agent do the same
thing but using fewer tokens, even if the end point is the
agent sending off a TAP query.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Is anyone else thinking about this? Can someone
from ESO ask Ashley to join IVOA Slack to discuss this?</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Each data center could put their own MCP server
up with their own targeted API and that might be fine, but
pooling our experience in terms of what helped and what made
things worse would be really helpful and if we end up with
an IVOA Note containing advice on natural language queries
that would be great. If we ended up with a standardized
vocabulary for MCP servers that might be even better.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">-- </div>
<div dir="ltr">Tim Jenness</div>
<div dir="ltr">Rubin Observatory</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Andre Schaaff
Responsable R&D du CDS
Observatoire Astronomique de Strasbourg (ObAS)
UMR 7550 Universite de Strasbourg - CNRS
11, rue de l'Universite
F-67000 Strasbourg</pre>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
((( Sebastien Derriere <a class="moz-txt-link-abbreviated" href="mailto:sebastien.derriere@astro.unistra.fr">sebastien.derriere@astro.unistra.fr</a>
(. .) Observatoire de Strasbourg Phone +33 (0) 368 852 444
(( v )) 11, rue de l'universite Telefax +33 (0) 368 852 432
---m-m--- F-67000 Strasbourg France
</pre>
</body>
</html>