De spec is de dataset: waarom MCP-specificaties genoeg zijn om agent-evaluatie te synthetiseren - en waarom argument-waarden de blinde vlek blijven

Een agent die een tool aanroept, is pas betrouwbaar als je kunt aantonen dat hij de juiste tool met de juiste argumenten aanroept. Maar hoe evalueer je dat voor een tool-suite die nog geen evaluatiedata heeft? Handmatige scenario-curatie schaalt niet over tool-ecosystemen, statische benchmarks verouderen zodra een API verandert, en multi-turn evaluatie is vrijwel onmogelijk zonder toegang tot echte tool-responses.

De paper Agent Seer: Synthesizing Scenarios from Specification Understanding (arXiv:2608.26133, Apple) beantwoordt deze cold-start vraag met een opvallend eenvoudig inzicht: tool-specificaties bevatten al genoeg semantische informatie om realistische evaluatiescenario's te synthetiseren. Functienamen, natuurlijke-taalbeschrijvingen en getypeerde parameter-schemas, de structuur die een MCP-server al publiceert, volstaan om graded scenarios, synthetische tool-outputs en data-grounded multi-turn dialogen te genereren, zonder voorbeelden, zonder live tool access en zonder domein-specifieke tuning.

De empirische analyse over zeven MCP-specificaties levert echter een tweede, minder comfortabele bevinding op. De kwaliteit van gegenereerde scenario's wordt niet begrensd door de grootte van de tool-suite, maar door de complexiteit van de parameter-schemas. En de dominante failure mode, argument-waarde-accuraatheid, is structureel onzichtbaar voor de coarse name-match metrics die de meeste agent-evaluaties gebruiken.

Mijn hoofdstelling luidt:

MCP-specificaties bevatten genoeg semantische informatie om evaluatie-harnesses te synthetiseren, maar de kwaliteit wordt begrensd door parameter-schema complexiteit, niet door tool-suite grootte. De dominante failure mode, argument-waarde-accuraatheid, is structureel onzichtbaar voor coarse name-match metrics, wat betekent dat agent-evaluatie die alleen op tool-selectie en -naam matcht, systematisch de meest voorkomende foutklasse mist.

1. Het probleem: cold-start evaluatie van tool-calling agents

De paper identificeert drie problemen die de huidige staat van agent-evaluatie beperken.

De curatie-bottleneck. Realistische evaluatiescenario's moeten gebruikersintentie verbinden aan specifieke tool-calls, parameters vullen met plausibele waarden, en vastleggen hoe tools over conversatieturns heen ketenen. Handgeschreven benchmarks (GAIA, AgentBench, WorkArena) produceren high-fidelity scenario's, maar hun dekking wordt begrensd door curatie-inspanning. Schalen over de combinatorische ruimte van tool-paden is onpraktisch met de hand.

Het statische-benchmark-probleem. Een vast benchmark stopt de realiteit te weerspiegelen zodra tool-APIs evolueren. Een agent die hoog scoort op een snapshot-benchmark kan worden geëvalueerd tegen tool-beschrijvingen die niet meer overeenkomen met de productieomgeving.

De multi-turn evaluatie-gap. Conversationele agents vereisen evaluatie over interactiesequenties, niet alleen single-turn prompts. Het genereren van multi-turn scenario's waarin vervolgturns reageren op specifieke tool-outputs, in plaats van generieke instructies te herhalen, is bijzonder moeilijk zonder toegang tot echte tool-responses.

Samen definiëren deze het cold-start evaluatieprobleem: het produceren van realistische evaluatiedata voor een tool-suite die er geen heeft. Het tekort is het scherpst voor nieuwe, private of snel evoluerende APIs, en blijft bestaan over de lange staart van enterprise tool-suites die publiek beschreven systemen wrappen of uitbreiden.

2. Het kerninzicht: de spec is de dataset

De paper observeert dat tool-specificaties, functienamen, natuurlijke-taalbeschrijvingen en getypeerde parameter-schemas, al veel van de semantische informatie coderen die nodig is om evaluatiedata te synthetiseren: genoeg voor een LLM om plausibele workflows af te leiden, parameters te vullen met realistische waarden, te synthetiseren hoe tool-responses eruit zouden zien, en multi-turn dialogen te construeren die in die synthetische data zijn gegrond.

De bottleneck verschuift van menselijke curatie naar gestructureerde extractie.

Dit positioneert Agent Seer in een specifieke niche van de literatuur. De paper onderscheidt drie clusters van synthetische-datageneratie:

Cluster	Aanpak	Voorbeelden
Trainingstrajecten uit live executie	Echte tool-uitvoering voor fine-tuning	APIGen, TOUCAN (1.5M trajecten), GEM, Agent World Model
Gesimuleerde tool-omgevingen	Live tools vervangen door simulaties	Simia, Gecko, LOGIGEN, τ-bench, ToolSandbox
Spec-only generatie	Synthetische data puur uit specificaties	DiGiT-TC, FuncBenchGen, Agent Seer

Agent Seer neemt alleen tool-specificaties als input (zoals spec-only systemen), maar gebruikt een LLM om plausibele tool-responses te synthetiseren in plaats van een runtime-omgeving te vereisen (zoals gesimuleerde omgevingen voor evaluatie). De bijdrage is niet het prompt-gedreven generatiemechanisme, gedeeld met APIGen, TOUCAN en anderen, maar de structuur die erop wordt gelegd: een vier-fase pipeline met gevalideerde gestructureerde outputs op elke grens, die harnesses produceert die ontkoppeld zijn van elke executie-backend.

3. De vier-fase pipeline

Agent Seer realiseert dit als een vier-fase pipeline die ruwe MCP-tool-specificaties omzet in self-contained evaluatie-harnesses. Elke fase consumeert gevalideerde gestructureerde outputs van de vorige, zodat schema-schendingen worden opgevangen aan de grenzen in plaats van downstream te propageren.

Fase 1: Tool-interpretatie. Deze fase zet ruwe MCP-tool-specificaties om in semantisch verrijkte beschrijvingen. Voor elke tool stuurt de module een gestructureerde prompt naar een LLM met vier semantische velden: een functionele beschrijving, vereiste parameters met semantische rollen, primaire use case, en organisatorische context. Dit verbindt terse API-documentatie aan rijkere scenario's.

Fase 2: Scenario-generatie. Deze module produceert realistische enterprise-workflow-scenario's op twee complexiteitsniveaus. Eenvoudige scenario's richten zich op alledaagse operationele taken: single-domain, korte tool-call-ketens. Complexe scenario's richten zich op nieuwe, multi-domain workflows die tools op geavanceerde manieren combineren. Beide niveaus worden geïmplementeerd via prompt-engineering in plaats van structurele constraints.

Elk gegenereerd scenario bevat een titel, gebruikersinstructie, geordende lijst van verwachte tool-calls met parameterwaarden, novelty-verklaring en een natuurlijke vervolgvraag. Het output-schema embedt gestructureerde reasoning-trace-velden: elke tool-call draagt een quick_explanation die rechtvaardigt waarom de call wordt gemaakt, en elk scenario bevat een novelty_reason die de evaluatiewaarde verklaart. Deze velden dwingen de LLM om te redeneren over tool-selectie en workflow-compositie tijdens generatie.

Fase 3: Mock-output-generatie. Voor elke functie-call in de sequentie produceert de module een synthetische tool-output. De pipeline accepteert een optioneel example-outputs-veld, waardoor het een spectrum is: volledig unsupervised vanuit specificaties alleen, maar in staat om beschikbare traces te incorporeren om de getrouwheid te verbeteren. Wanneer voorbeelden worden gegeven, matcht de generator hun structuur; wanneer ze afwezig zijn, vertrouwt generatie op de tool-beschrijving alleen. Elke mock-output draagt een grounding-tier (hoog/midden/laag) die de beschikbaarheid van referentiemateriaal registreert.

Fase 4: Multi-turn expansie. Deze fase neemt een scenario en zijn mock-outputs en emitteert een lijst van conversationele turns. De splits richten zich op natuurlijke fasegrenzen, zodat de resulterende turns twee multi-turn tool-calling-patronen oefenen die door BFCL v3 zijn geformaliseerd: multi-step sequenties, waarin elke call afhangt van de output van de vorige, en multi-hop patronen, waarin onafhankelijke calls informatie verzamelen die moet worden gesynthetiseerd. Splitsen op fasegrenzen (in plaats van op willekeurige punten) behoudt deze afhankelijkheidsstructuren over turns heen.

Wanneer de expansie slaagt, verwijzen vervolgturns naar concrete waarden uit synthetische outputs, entiteitsnamen, tellingen, statuscodes, in plaats van abstracte taakbeschrijvingen, waardoor data-grounded multi-turn dialogen ontstaan.

Het harness-artefact. De vier fasen produceren een self-contained evaluatie-harness met vijf velden: prompt (natuurlijke-taaltaskdoel), expected_tools (geordende AgentCall-objecten met naam en getypeerde args), mock_outputs (synthetische JSON-respons per call met grounding-tier), conversation (multi-turn dialoog die mock-output-waarden refereert), en oracle (expected_tools, held-out van de agent voor scoring). Een downstream-framework presenteert de prompt, voert mock-outputs als tool-responses in, en scoort de geëmitteerde calls van de agent tegen de scenario-workflow als de held-out oracle, waardoor evaluatie op een voorheen ongeziene tool-suite mogelijk is zonder live access.

4. De evaluatiemethodologie: vier dimensies, cascading penalties

De kwaliteitsbeoordeling gebruikt LLM-as-judge scoring langs twee complementaire dimensies: tool-calling correctheid (TC) en conversationele coherentie (Coh).

De tool-calling-evaluator scoort onafhankelijk vier dimensies, waarmee het coarse pass/fail-signaal van de meeste eerdere werk wordt gedecomposeerd in orthogonale assen:

Dimensie	Sub-dimensies	Opmerking
Usage	Necessity, overuse-detectie	Necessity domineert; overuse is diagnostisch, uitgesloten van aggregatie
Selection	Correctness, specificity, completeness	Gemiddelde van sub-scores
Ordering	Sequence logic, dependency handling, execution efficiency	N/A bij single tool-call, dan uitgesloten
Arguments	Completeness, name, value, type, format, relevancy	Zes sub-dimensies

De cascading penalties zijn cruciaal. Een verkeerde parameternaam of ontbrekende vereiste parameter zet value, type en format op nul; een verkeerde waarde cascadeert naar type, format en relevancy. Een enkele kritieke fout stort dus het argument-gemiddelde in. Dit is een bewuste methodologische keuze die de paper onderscheidt van coarse name-match metrics.

De vier dimensies combineren via rekenkundig gemiddelde per turn; conversatiescores zijn het rekenkundig gemiddelde van turnscores. De coherentie-evaluator beoordeelt vijf sub-aspecten, logische flow, volledigheid, beknoptheid, topic-relevantie en context-retentie, op een 1-3 schaal, genormaliseerd naar 0-1.

5. De resultaten: kwaliteit, dekking en de twee kernbevindingen

De pipeline werd geëvalueerd op zeven open-source MCP-specificaties die diverse domeinen, tool-aantallen en schema-complexiteiten bestrijken: Illustrator (64 tools), Selenium (56), Redis (47), Git (33), Elasticsearch (20), Slack (16) en Filesystem (14). De pipeline genereerde 337 scenario's, die 391 evaluatie-records opleverden.

Algehele kwaliteit. De pipeline behaalt een gemiddelde unsupervised tool-calling-score van 0.911 (95% bootstrap CI [0.897, 0.925]; mediaan 0.979) en gemiddelde coherentie van 0.855 (95% CI [0.838, 0.872]; mediaan 0.933). 31.7% van de records behaalt een perfecte tool-calling-score, terwijl slechts 2.3% onder 0.5 scoort. Alle zeven MCPs overschrijden 0.85; alle overschrijden 0.91 op eenvoudige scenario's.

Bevinding 1: parameter-schema complexiteit, niet tool-suite grootte, is de sterkste correlatie met kwaliteitsvariatie. Op per-MCP-grain (n=7) correleert tool-aantal positief maar bescheiden met gemiddelde unsupervised tool-calling (r=+0.40), terwijl parameter-schema complexiteit negatief correleert, gemiddelde parameters per tool (r=-0.60) en optionele-parameter-fractie (r=-0.66). De twee effecten werken op verschillende assen van een MCP en heffen elkaar niet op: Selenium (56 tools) scoort 0.935 terwijl Filesystem (14 tools) 0.876 scoort, maar Git (33 tools, 11.2 gemiddelde parameters) is het laagst op 0.857.

Op tool-niveau (n=222) bevestigt de disaggregatie de richting met substantieel grotere steekproef: parameter-aantal en optionele-fractie correleren beide negatief met gemiddelde TC (r=-0.29 en -0.30, beide p ＜ 0.001). Dezelfde schema-kenmerken correleren ook negatief met gemiddelde coherentie op tool-niveau (r=-0.41 en -0.34, beide p ＜ 0.001). Deze tweede bevinding, niet detecteerbaar op per-MCP-grain, suggereert dat complexe parameters niet alleen tool-calling correctheid degraderen, maar ook het vermogen van de agent om helder te communiceren rond die tools.

Bevinding 2: argument-waarde-accuraatheid is de dominante failure mode, onzichtbaar voor coarse metrics. Alleen 42% van de records scoort perfect op argumenten; 57% scoort gedeeltelijk. Waarde-accuraatheid domineert argument-fouten (223 records), gevolgd door relevancy (44), format (35), type (31), compleetheid (16) en naam-accuraatheid (11). De pipeline genereert betrouwbaar correcte parameternamen en -types, maar worstelt met precieze waarden, met name voor optionele parameters met ambigue semantiek.

De paper illustreert dit met een representatief Redis-voorbeeld. Verschillende Redis-commando's dragen optionele parameters die de pipeline weglaat wanneer context ze impliceert. Het set-commando accepteert bijvoorbeeld een optioneel expiration-veld dat vaak wordt overgeslagen wanneer het scenario tijdgebonden opslag impliceert. De pipeline genereert consistent de correcte functienaam, key en value-argumenten, maar laat dit expiry-parameter weg, wat het argument-scoring-framework als een compleetheid-subdimensie-fout markeert. Een coarse name-match metric zou deze records als volledig correct scoren. Dit patroon, correcte tool-selectie met subtiel onvolledige argument-specificatie, is de primaire driver van Redis-fouten en illustreert waarom argument-correctheid onder het functie-call-niveau moet worden gedecomposeerd.

6. Failure-mode analyse: pretraining-leak en parameter-overload

De paper identificeert twee distincte failure-mechanismen in Git, die op verschillende scenario-complexiteiten opereren.

Pretraining-leak tool-name hallucinatie (eenvoudige scenario's). In drie Git-scenario's emitteert de pipeline echte Git CLI-commando's die niet in de MCP-specificatie zitten (fetch, revert, filter-repo), een pretraining-kennisleak voorbij de spec. Deze drie records zijn verantwoordelijk voor de helft van Git's zes records met TC ＜ 0.5 en voor de kloof tussen Git's eenvoudige-scenario TC (0.910) en de andere zes MCPs (0.93-0.99). Over de volledige corpus zijn gehallucineerde calls 0.336% van alle tool-invocaties (3 van 893), volledig geconcentreerd in Git.

Parameter-overload (complexe scenario's). Git-tools hebben gemiddeld 11.2 parameters (3x de op één na hoogste), 95% optioneel, en de ref-parameter verschijnt in zeven tools met verschillende semantiek ("commits vanaf" in log, "vergelijk tegen" in diff, "toon object op" in show). De pipeline selecteert de juiste tool (selectie-score 0.802) maar genereert incorrecte parameterwaarden, wat een gemiddelde argument-score van 0.780 produceert, de laagste van elke MCP. Complexe Git-scenario's degraderen verder (argumenten 0.726) naarmate multi-tool-workflows per-call parameterfouten samenstellen.

Coherentie-taxonomie. De meest voorkomende coherentie-issues zijn ontbrekende informatie of ondiepe respons (373 records), off-topic (130), non-sequitur (86) en zelf-tegenspraak of hallucinatie (85). Record-level TC en coherentie blijven zwak gecorreleerd (r=0.23), en het "correcte tools, slechte coherentie"-kwadrant (23% van records op een 0.75-drempel) beslaat alle MCPs in plaats van zich in één domein te concentreren, coherentie-tekorten zijn een algemene pipeline-eigenschap.

7. Judge-robustheid: de out-of-family replicatie

De paper adresseert de LLM-as-judge circulariteitszorg, dat scenario's die "er goed uitzien voor een LLM" goed scoren ongeacht werkelijke kwaliteit, op twee manieren.

Ten eerste een evaluator-generator-capaciteitskloof: de judge (Gemini 2.5 Flash) heeft surplus-capaciteit over de zwakkere generator (Gemini 2.5 Flash Lite), consistent met teacher-student evaluatieparadigma's. Empirisch discrimineert de judge betekenisvolle, domein-specifieke failure-patronen (argument-cascading, semantische ambiguïteit in Redis) in plaats van uniform hoge scores te produceren.

Ten tweede een out-of-family replicatie: de volledige 391-record corpus werd hergescoord met Qwen3.5-122B-A10B-FP8 (Alibaba-familie). De resultaten zijn robuust voor tool-calling: geen gemiddelde verschuiving (ΔµTC≈0, 95% CI [-0.009, +0.008]), record-level paired r=0.79, per-MCP CIs overlappen voor alle zeven MCPs, en de MCP-rangschikking wordt behouden (ρ=0.86). De dominante argument-waarde-accuraatheid failure mode repliceert bilateraal met een 4-5x marge (Gemini 240 records, Qwen 252).

Coherentie is echter systematisch strenger onder de out-of-family judge (ΔµCoh≈-0.16, paired r=0.42), en de MCP-level coherentie-rangschikking is slechts gedeeltelijk behouden (ρ=0.46). De slechtste-coherentie MCP verschilt per judge (Git onder Gemini, Illustrator onder Qwen 3.5). Absolute coherentieniveaus en MCP-level coherentie-rangbehoud moeten daarom als judge-afhankelijk worden gelezen.

8. Publieke-sector translatie: BIO2/NIS2, EU AI Act art. 14 en de inrichting van agent-evaluatie

De bevindingen raken direct aan de inrichting van agent-evaluatie in de publieke sector.

BIO2/NIS2 en de evaluatie-eis. Voor NIS2-organisaties die MCP-gebaseerde agenten overwegen (documentverwerking, zaaksystemen, databankintegraties), is de cold-start evaluatievraag cruciaal: hoe toon je aan dat een agent correcte tool-calls doet vóór productie, zonder live systemen te raken? Agent Seer biedt een methodologie die dit mogelijk maakt, evaluatie-harnesses gegenereerd uit de MCP-specificatie zelf, zonder live tool access. Dit is direct relevant voor de risicobeoordeling die BIO2/NIS2 vereist: je kunt een agent valideren tegen een synthetische omgeving die de productie-tool-suite modelleert.

EU AI Act art. 14 (menselijk toezicht). Artikel 14 vereist dat hoogrisico-AI-systemen zo worden ontworpen dat natuurlijke personen ze effectief kunnen toezien. De paper toont dat de kwaliteit van agent-evaluatie, en dus de basis voor menselijk toezicht, wordt begrensd door de metrics die je kiest. Een evaluatie die alleen op tool-selectie en -naam matcht, mist systematisch de dominante foutklasse (argument-waarde-accuraatheid). Voor een deployer betekent dit dat de keuze van het evaluatiemechanisme onderbouwd moet zijn, niet alleen aanwezig.

De governance-les: coarse metrics zijn een blinde vlek. De meest overdraagbare les is methodologisch. De paper toont dat argument-waarde-accuraatheid, de dominante failure mode, structureel onzichtbaar is voor coarse name-match metrics. Dit is een governance-les voor hoe je agent-evaluatie inricht: de keuze van de evaluatiemetric bepaalt welke fouten je ziet, en een metric die de meest voorkomende foutklasse mist, geeft een vals gevoel van veiligheid.

Pretraining-leak als security-relevant patroon. De Git-hallucinatie (fetch, revert, filter-repo, echte CLI-commando's die niet in de goedgekeurde MCP-specificatie zitten) is een security-relevant patroon. Een agent kan tools aanroepen die niet in de goedgekeurde set zitten, gedreven door pretraining-kennis in plaats van de actuele specificatie. Voor een organisatie die MCP-servers als security boundary gebruikt, is dit een risico dat in de evaluatie moet worden opgenomen: de evaluatie moet controleren dat de agent alleen tools uit de goedgekeurde specificatie aanroept.

9. Falsifieerbare hypotheses en beperkingen

De paper is methodologisch sterk maar kent beperkingen die de conclusies begrenzen.

H1: "MCP-specificaties bevatten genoeg semantische informatie om realistische evaluatiescenario's te synthetiseren." Deze hypothese wordt ondersteund over zeven diverse MCPs, met complete tool-dekking op kleine en middelgrote specificaties en sterke kwaliteit (mean TC 0.911). De ondersteuning is echter begrensd door de coverage-ceiling bij 64 tools (Illustrator, 56%).

H2: "Parameter-schema complexiteit, niet tool-suite grootte, is de sterkste correlatie met kwaliteitsvariatie." Deze hypothese wordt ondersteund op beide grains (per-MCP r=-0.60/-0.66; tool-level r=-0.29/-0.30, p ＜ 0.001). De ondersteuning is robuust voor aggregatieregel (arith/harm/min) en judge-swap.

H3: "Argument-waarde-accuraatheid is de dominante failure mode." Deze hypothese wordt ondersteund en is robuust voor judge-swap (4-5x marge onder beide judges). De ondersteuning is echter gebaseerd op LLM-generated ground truth, wat de circulariteitszorg niet volledig wegneemt.

Beperkingen. (1) De meest significante beperking is de afhankelijkheid van LLM-generated ground truth, die systematische biases van het genererende model introduceert. De paper positioneert het framework terecht als een proxy-evaluatietool die brede capaciteitsgaten en relatieve prestatieverschillen identificeert, niet als een absolute maat. (2) Cross-call referentiële integriteit: mock-outputs voor sequentiële calls worden onafhankelijk gegenereerd, waardoor IDs of waarden mogelijk niet over afhankelijke calls heen uitlijnen. (3) De coverage-ceiling bij 64 tools suggereert dat gerichte generatiestrategieën nodig zijn voor grotere specificaties. (4) Zeven MCP-specificaties en een enkel generatiemodel (Gemini 2.5 Flash Lite) kunnen geen universele claims vestigen. (5) Multi-turn evaluatie-records zijn beperkt (n=54), met expansie zwaar scheef naar complexe scenario's (30.8% expansierate vs. 2.8% voor eenvoudige), wat de statistische power voor multi-turn bevindingen beperkt. (6) Een systematische menselijke evaluatiestudie die framework-scores correleert met menselijke kwaliteitsoordelen blijft een belangrijke richting voor toekomstig werk.

10. Conclusie

De paper levert een zeldzaam stuk empirisch bewijs over een vraag die de publieke sector nu moet beantwoorden: hoe evalueer je een tool-calling agent zonder live systemen te raken? Het antwoord is dat de MCP-specificatie zelf genoeg semantische informatie bevat om evaluatie-harnesses te synthetiseren, een methodologie die schaalt met het tool-ecosysteem in plaats van te verouderen.

Maar de empirische analyse onthult een structurele blinde vlek die de inrichting van agent-evaluatie bepaalt. De kwaliteit van gegenereerde scenario's wordt begrensd door parameter-schema complexiteit, niet door tool-suite grootte. En de dominante failure mode, argument-waarde-accuraatheid, is onzichtbaar voor de coarse name-match metrics die de meeste agent-evaluaties gebruiken. Een evaluatie die alleen op tool-selectie en -naam matcht, mist systematisch de meest voorkomende foutklasse.

Voor de publieke sector is de operationele les concreet. Een organisatie die MCP-gebaseerde agenten inricht onder BIO2/NIS2 moet de evaluatiemetric expliciet kiezen, en die keuze bepaalt welke fouten zichtbaar zijn. Een evaluatie die argument-waarden niet decomposeert, geeft een vals gevoel van veiligheid. En de pretraining-leak hallucinatie toont dat een agent tools kan aanroepen die niet in de goedgekeurde specificatie zitten, een risico dat in de evaluatie moet worden opgenomen.

De kern is dat de spec de dataset is, maar dat de metric de blinde vlek bepaalt. Een evaluatie die de meest voorkomende foutklasse niet kan zien, is geen evaluatie, het is een bevestiging.