Tools en MCP

Tools maken van tekst een actie

Een model zonder tools kan alleen tekst schrijven. Een model met tools kan een ticket lezen, een tabel bevragen of een bericht sturen. Op dat moment gaat een agent risico dragen. In deze les ontwerpen we tools zo dat een verkeerde beslissing van het model klein blijft.

We behandelen drie regels: eerst lezen, gevolgen laten goedkeuren en elke tool een eigen afgebakende identiteit geven. Hoe je een MCP-server van nul bouwt behandelen we niet. De officiële documentatie doet dat goed, en we linken ernaar aan het eind.

Wat MCP je geeft

Het Model Context Protocol (MCP) is een open protocol om tools aan modellen aan te bieden. Een client vraagt een server welke tools er zijn (tools/list) en roept er daarna een aan (tools/call). Elke tool heeft een naam, een beschrijving en een invoerschema in JSON Schema. Het model ontdekt en kiest tools op basis van die metadata. Daarom is de beschrijving onderdeel van je beveiligingsoppervlak en niet alleen documentatie.

De MCP-specificatie zegt dat er ALTIJD een mens in de lus hoort te zijn die een toolaanroep kan weigeren. Ook staat erin dat servers alle toolinvoer MOETEN valideren, toegangsbeheer MOETEN inrichten, aanroepen MOETEN begrenzen en uitvoer MOETEN opschonen. Clients moeten annotaties van tools als onbetrouwbaar behandelen, tenzij ze van een vertrouwde server komen.

Een tool die faalt, moet dat melden op een manier die het model kan gebruiken. MCP maakt onderscheid tussen protocolfouten en uitvoeringsfouten van tools. Bij de tweede soort bevat het resultaat isError: true en een melding zoals "vertrekdatum moet in de toekomst liggen", zodat het model zichzelf kan corrigeren en opnieuw kan proberen.

MCP op Databricks

Databricks beschrijft drie soorten MCP-servers: door Databricks beheerde servers (bijvoorbeeld voor SQL), externe servers die je toevoegt en eigen servers die je bouwt, inclusief servers die een REST-API inpakken via Databricks Apps. Unity Catalog-rechten sturen de beheerde en geregistreerde servers aan. Unity Gateway kan toegang regelen, credentials beheren en gebruik bewaken, en je kunt beperken welke tools een agent mag zien. Netwerktoegang kun je beperken met IP-toegangslijsten, netwerkbeleid en privéconnectiviteit.

De huidige documentatie geeft geen statuslabel per soort server. Controleer de releasenotes voor je een klant een beheerde server in productie belooft.

Regel 1: eerst lezen

Verdeel je tools in twee klassen en behandel ze verschillend.

Begin een agent met alleen leestools. Voeg een schrijftool toe als de evaluatieset laat zien dat de agent goed leest. Laat de agent bij de eerste schrijftool de actie voorstellen en laat een mens bevestigen. Een voorstel is goedkoop af te wijzen. Een verstuurde e-mail niet.

Regel 2: één afgebakende identiteit per tool

Een agent met één krachtig service-account maakt elke tool zo gevaarlijk als de gevaarlijkste tool. Geef elke tool, of elke groep tools, een eigen service principal en geef die het minimum in Unity Catalog. In onze delivery standards is dit de regel van least privilege: rechten gaan naar groepen, geprivilegieerde toegang is tijdelijk en automatisering gebruikt service principals, nooit persoonlijke accounts.

Handelt de agent namens een gebruiker, dan moet de aanroep met de rechten van die gebruiker draaien. Databricks-apps kunnen gebruikers laten inloggen en tools per gebruiker aanroepen, zodat de agent niet kan lezen wat de gebruiker niet mag lezen. Ons artikel over on-behalf-of-toegang in Databricks Apps laat zien waarom één gedeelde krachtige identiteit de verkeerde standaard is.

-- Geef de service principal van de agent leesrechten op één schema, niets meer.
-- Groeps- en schemanamen volgen de NexOps-naamgeving.
GRANT USE CATALOG ON CATALOG prd_support TO `grp-uc-prd-support-gold-reader`;
GRANT USE SCHEMA  ON SCHEMA  prd_support.gold TO `grp-uc-prd-support-gold-reader`;
GRANT SELECT      ON SCHEMA  prd_support.gold TO `grp-uc-prd-support-gold-reader`;

De GRANT-statements volgen de syntaxis van Unity Catalog-privileges. De service principal van de agent is lid van de readergroep. Dit patroon werken we uit in de governancecursus.

Regel 3: ontwerp tools voor het model

Goed toolontwerp is de helft van de kwaliteit van een agent.

• Weinig tools. Tien goed benoemde tools verslaan veertig overlappende. Het model kiest beter uit een korte lijst.
• Smalle tools. get_order_status(order_id) is veiliger dan run_sql(query). Met een vrije SQL-tool kan een promptinjectie om elke tabel vragen.
• Strikte schema's. Definieer typen, enums en verplichte velden. Weiger al het andere voor het je systeem bereikt.
• Bruikbare fouten. Geef terug wat er mis was en hoe een geldige aanroep eruitziet.
• Begrensde uitvoer. Geef een beperkt aantal rijen terug en kort lange tekst in. Uitvoer die het contextvenster vult, verdringt de taak.
• Idempotente schrijfacties. Een herhaalde aanroep mag geen duplicaat maken. Agents proberen opnieuw.

Een tooldefinitie

{
  "name": "get_order_status",
  "description": "Return the status of one order. Read only. Use when the user asks where an order is.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string", "description": "Order number, for example SO-100234" }
    },
    "required": ["order_id"],
    "additionalProperties": false
  }
}

De vorm volgt de tooldefinitie in de MCP-specificatie. De regel additionalProperties: false maakt het schema strikt, en de beschrijving zegt dat de tool alleen leest.

Goedkeuringen

Voeg een menselijke stap toe voor elke actie met gevolgen: geld, externe berichten, verwijderen, toegangswijzigingen. Toon de persoon de exacte actie en de invoer, geen samenvatting van het model. Leg vast wie wat goedkeurde. Na verloop van tijd laten de evaluatieset en de goedkeuringslogs zien welke acties automatisch kunnen. Dat is een besluit met bewijs, geen onderbuikgevoel.

Samenvatting

Begin met leestools. Geef elke tool een eigen afgebakende identiteit. Houd tools weinig, smal en strikt. Zet een mens voor elke actie met gevolgen en log de goedkeuring.

Volgende les: geheugen en state, de bouwsteen die een agent over sessies heen nuttig maakt en over gebruikers heen riskant.