Documentation Index

Fetch the complete documentation index at: https://docs.document360.com/llms.txt

Use this file to discover all available pages before exploring further.

Disclaimer: Dit artikel is gegenereerd door automatische vertaling.

MCP versus standaard API

Prev Next

Naarmate meer teams AI-agenten integreren in hun documentatieworkflows, rijst een veelvoorkomende architecturale vraag: wanneer Document360 zowel MCP-endpoints als standaard API-endpoints aanbiedt, welke zou een AI-agent als Claude Code moeten gebruiken, en wanneer?

Dit artikel legt uit hoe je over die beslissing kunt nadenken, wanneer je elke interface moet gebruiken, en hoe een hybride aanpak vaak het beste van beide biedt.


Inzicht in de twee interfaces

De MCP-interface biedt een samengestelde set tools - zoeken, ophalen, creëren, bijwerken, workflows beheren en content publiceren - via een gestructureerd protocol dat AI-agenten native begrijpen. Wanneer een agent via MCP verbinding maakt, kan hij ontdekken welke bewerkingen beschikbaar zijn, hun input/output-schema's begrijpen en deze aanroepen als onderdeel van een redeneerketen, allemaal zonder aangepaste lijmcode.

De standaard API geeft je directe, laag-niveau toegang tot de volledige mogelijkheden van Document360 via REST-eindpunten. Je beheert expliciet elke verzoekparameter, herkansingslogica, paginering en authenticatieflow.

Beide interfaces communiceren met dezelfde onderliggende kennisbasis. Het verschil zit in hoe een agent (of jouw code) ermee omgaat.


Standaard gebruik MCP wanneer de agent het ondersteunt

MCP is speciaal ontworpen voor AI-agenten. Wanneer de MCP-server van Document360 beschikbaar is en de benodigde operatie dekt, zou het je eerste keuze moeten zijn voor agentische workflows. Hier is waarom:

Geen lijmcode nodig - De agent ontdekt de beschikbare tools dynamisch. Je hoeft geen aangepaste request builders te schrijven of ruwe API-antwoorden te parsen voor veelvoorkomende bewerkingen zoals het zoeken in artikelen of het ophalen van categoriestructuren.

Gestructureerde inputs en outputs - Elke MCP-tool heeft een gedefinieerd schema. Dit vermindert fouten veroorzaakt door verkeerd gevormde verzoeken en maakt het gedrag van agenten voorspelbaarder.

Natuurlijke geschiktheid voor meerstapsredeneren - AI-agenten blinken uit in het aan elkaar rijgen van acties zoals het zoeken naar een artikel, het lezen van de inhoud en het vervolgens bijwerken op basis van wat er is gevonden. MCP-tools zijn precies ontworpen voor dit soort sequentiële, contextbewuste workflow.

Gestandaardiseerde authenticatie en contextoverdracht - MCP behandelt OAuth en context op een consistente manier tussen services, waardoor integratiewrijving wordt verminderd wanneer je agent verbinding maakt met meerdere systemen.


Gebruik de standaard API wanneer je controle nodig hebt

De MCP-server stelt een gecureerde subset van het volledige API-oppervlak van Document360 beschikbaar. Er zijn gevallen waarin het logischer is om naar de standaard API te gaan:

De operatie wordt niet via MCP blootgesteld - Controleer of de specifieke functionaliteit die je nodig hebt — een bepaald filter, een bulk-export, een webhook-trigger — beschikbaar is in de ondersteunde MCP-tools. Als dat niet zo is, is de standaard API jouw pad.

Je hebt prestatieoptimalisaties nodig - Als je workflow bestaat uit het batchen van veel verzoeken, het streamen van grote payloads of het agressief cachen van reacties, geeft de standaard API je de controlehefbomen die MCP-abstracties niet hebben.

Je bouwt non-agentische automatisering - Cron-jobs, datapipelines en webhook-handlers profiteren niet van toolontdekking of agentisch redeneren. Een directe API-aanroep is eenvoudiger en beter onderhoudbaar in deze contexten.

Je hebt nauwkeurige paginering of herkansingscontrole nodig - De standaard API geeft je volledige controle over hoe je door grote resultatensets loopt en tijdelijke fouten behandelt, wat belangrijk is voor betrouwbaarheidsgevoelige automatisering.


Een hybride aanpak werkt in de praktijk vaak het beste.

Voor de meeste teams die met AI-agenten bouwen, is de ideale architectuur geen binaire keuze. Het is gelaagd:

Laag Interface Doel
Redeneren en handelen als agent MCP Zoek, ophalen, creëren, bijwerken, workflows beheren en publiceren via Natural Tool-gebruik
Precisieoperaties Standaard API Batchverwerking, niet-ondersteunde operaties, prestatiekritische paden
Achtergrondautomatisering Standaard API Pipelines, cron-jobs, webhooks die geen tool-ontdekking nodig hebben

Denk er zo over: laat de agent MCP gebruiken voor waar agenten goed in zijn - redeneren over welke tool ze moeten aanroepen, acties over meerdere stappen aaneenjagen en werken met gestructureerde documentatie-inhoud. Reserveer directe API-aanroepen voor deterministische, prestatiegevoelige of niet-ondersteunde bewerkingen waar expliciete controle belangrijk is.


Praktische checklist voordat je kiest

Voordat je beslist welke interface je voor een bepaalde operatie gebruikt, werk je deze vragen door:

  1. Is de operatie beschikbaar als een MCP-tool? Bekijk de tools die in het artikel Ondersteunde tools worden vermeld. Zo ja, geef dan de voorkeur aan MCP.
  2. Moet de makelaar nadenken over welke actie hij moet ondernemen? Als de agent dynamisch beslist wat hij vervolgens doet op basis van context, past MCP vanzelf.
  3. Moet je grote volumes verwerken of het gedrag op verzoekniveau aansturen? Zo ja, gebruik dan de standaard API.
  4. Is dit onderdeel van een niet-agentische automatisering (pipeline, scheduler, webhook)? Zo ja, gebruik dan direct de standaard-API — er is hier geen voordeel aan het ontdekken van tools.
  5. Verbind je meerdere diensten? Het gestandaardiseerde authenticatiemodel van MCP vermindert wrijving wanneer je agent met Document360 praat naast andere MCP-geschikte tools.

Hoe dit eruitziet in een echte workflow

Stel je voor dat een support engineer een AI-agent gebruikt om documentatiegaten te identificeren en op te vullen bij binnenkomende tickets.

De agent zou:

  1. Gebruik document360-mcp-search het om te controleren of relevante documentatie al bestaat
  2. Gebruik document360-mcp-get-article om het dichtstbijzijnde overeenkomende artikel op te halen en te lezen
  3. Gebruik document360-mcp-create-article het om een nieuw artikel op te stellen als er een gat wordt gevonden
  4. Gebruik document360-mcp-set-workflow-status het om het artikel te verplaatsen om te beoordelen en het juiste teamlid toe te wijzen
  5. Gebruik document360-mcp-publish-article het artikel om te publiceren zodra het is beoordeeld en goedgekeurd

Alle vijf stappen vinden plaats via MCP. De agent redeneert wat hij vervolgens moet doen in elke fase, en de toolschema's sturen de interactie.

Als datzelfde team ook elke nacht een pipeline uitvoert om alle artikelen te exporteren voor een extern auditsysteem, roept die pipeline direct de standaard API aan. Het heeft geen toolontdekking nodig; Het heeft alleen betrouwbare, gepagineerde toegang tot de inhoud van het artikel nodig op een schema.


Naarmate de MCP-dekking groeit

MCP-servers zijn in ontwikkeling. De huidige implementatie van Document360 omvat de meest voorkomende documentatiebewerkingen voor AI-agenten - zoeken, ophalen, contentbeheer, workflowbeheer en publicatie. In de loop van de tijd zal waarschijnlijk meer van het API-oppervlak via MCP worden blootgesteld, wat de balans voor de meeste agentische gebruiksgevallen verder richting MCP zal verplaatsen.

Voor nu is de praktische regel om te beginnen met MCP, terug te vallen op de standaard API voor hiaten, en je systeem zo te ontwerpen dat wisselen tussen de twee eenvoudig is.


FAQ

Kan een AI-agent binnen dezelfde workflow schakelen tussen MCP en de standaard API?

Ja. Een enkele workflow kan MCP gebruiken voor de redeneer- en actiestappen — zoeken, lezen, schrijven — en de standaard-API direct aanroepen voor operaties buiten het bereik van MCP. De twee interfaces sluiten elkaar niet uit; Ze hebben toegang tot dezelfde onderliggende kennisbasis.

Omzeilt het gebruik van de standaard API de machtigingen en zichtbaarheidsregels van Document360?

De twee interfaces behandelen permissies verschillend. MCP is afhankelijk van OAuth en bevat volledige gebruikerscontext, waardoor alle rolgebaseerde toegangscontroles worden gerespecteerd — de AI-agent kan alleen toegang krijgen tot inhoud die de geauthenticeerde gebruiker mag zien.

De standaard-API werkt met een API-token, dat het type toegestane bewerkingen aanstuurt (lezen, schrijven, verwijderen), maar geen toegang op portaal- of inhoudsniveau afdwingt. Het draagt de gebruikerscontext niet op dezelfde manier. Houd dit in gedachten bij het ontwerpen van workflows met gevoelige of beperkte inhoud — MCP is de meest geschikte interface waar rolgebaseerde zichtbaarheid belangrijk is.

Onze AI-agent ondersteunt MCP nog niet. Moeten we wachten of nu met de standaard API bouwen?

Bouw nu met de standaard API als je een werkend gebruiksscenario hebt. MCP-ondersteuning groeit op AI-platforms, maar er is geen reden om te wachten. Ontwerp je integratie zo dat de acties van de agent modulair zijn — dat maakt het makkelijker om later MCP-toolcalls in te voeren zonder de hele workflow te herstructureren.