Det här är en del 2 av | " | LLM som komponenter Del 1: Varför LLM misslyckas som sensorer omfattade kategoriska felet med att använda LLMs för perception. Denna artikel omfattar kategoriskafeln i att använda MCP som arkitektur

" Hur bygger jag en MCP-server?

SDKs existerar. En LLM kan bygga en byggnadsställning på några sekunder . Den verkliga frågan är

Vilken roll ska en MCP-server spela in i ett system som inte måste ligga

Den knappa förmågan är nu att designa system runt MCP: auktoritet, tillstånd, kontrollerability, och deterministisk kontroll. MCP hanterar transport — dessa intressen bor någon annanstans

Denna artikel förklarar hur jag använder MCP utan agenter, självstyre, eller viber, och varför de flesta MCP-exempler återskapar samma problem som vi

Vad är egentligen MCP?

MCP (Modella Kontextprotokollet) är ett kabelprotokoll. Den rör sig

• Inputs och utgångar
• Schemas
• verktygsmetadata
• Kapacitetsforskning

Det gör det. inte:

• Bestämma när verktygen borde fungera
• Validatera sanningen
• Kräv tillit
• Ta hand om biverkningar

flowchart LR
    subgraph MCP["MCP: What It Does"]
        Schema[Schema Discovery] --> Transport[Transport Layer]
        Transport --> Invoke[Tool Invocation]
        Invoke --> Response[Structured Response]
    end

    subgraph NotMCP["Not MCP's Job"]
        When[When to run?]
        Trust[Is this true?]
        Should[Should we act?]
        Safe[Is this safe?]
    end

    style MCP fill:none,stroke:#16a34a,stroke-width:2px
    style NotMCP fill:none,stroke:#dc2626,stroke-width:2px
    style Schema fill:none,stroke:#059669,stroke-width:2px
    style Transport fill:none,stroke:#059669,stroke-width:2px
    style Invoke fill:none,stroke:#059669,stroke-width:2px
    style Response fill:none,stroke:#059669,stroke-width:2px
    style When fill:none,stroke:#dc2626,stroke-width:2px
    style Trust fill:none,stroke:#dc2626,stroke-width:2px
    style Should fill:none,stroke:#dc2626,stroke-width:2px
    style Safe fill:none,stroke:#dc2626,stroke-width:2px

MCP är närmare OpenAPI än det är till en agent ram

Om du' använder MCP som ditt resonemangslayer, så har du redan gjort samma kategorisk fel som beskrivit i Del 1.

Om MCP är transport, så lever arkitekturen ovanför den.

grundprincipen : förslag mot beslut

Detta är grundregeln från Reduzerad RAG och Begränsad otydighet:

• Probabilistiska komponenter föreslår
• Deterministiska system bestämmer

I mina system:

• LLMs är aldrig myndigheter
• verktygen är aldrig självständig
• Varje MCP-respons är förslag, inte ett faktum

"Deterministiskt " här betyder inte regeln, -, styrd, ,, reproducerad, M SK2 och auditerad.

flowchart TD
    subgraph Proposers["Proposers (Probabilistic)"]
        LLM[LLM Synthesis]
        MCP1[MCP Tool Response]
        MCP2[MCP Tool Response]
    end

    subgraph Constrainer["Constrainer (Deterministic)"]
        Validate[Validate Proposals]
        Compare[Compare Confidence]
        Policy[Apply Policy Rules]
        Decide[Accept / Reject / Escalate]
    end

    subgraph Persistence["Persistence (Facts)"]
        Facts[(Verified Facts<br/>With Provenance)]
    end

    LLM --> Validate
    MCP1 --> Validate
    MCP2 --> Validate
    Validate --> Compare
    Compare --> Policy
    Policy --> Decide
    Decide --> Facts

    style Proposers fill:none,stroke:#d97706,stroke-width:2px
    style Constrainer fill:none,stroke:#2563eb,stroke-width:2px
    style Persistence fill:none,stroke:#16a34a,stroke-width:2px
    style LLM fill:none,stroke:#d97706,stroke-width:2px
    style MCP1 fill:none,stroke:#d97706,stroke-width:2px
    style MCP2 fill:none,stroke:#d97706,stroke-width:2px
    style Validate fill:none,stroke:#2563eb,stroke-width:2px
    style Compare fill:none,stroke:#2563eb,stroke-width:2px
    style Policy fill:none,stroke:#2563eb,stroke-width:2px
    style Decide fill:none,stroke:#2563eb,stroke-width:2px
    style Facts fill:none,stroke:#16a34a,stroke-width:3px

MCP-servern bestämmer inte.

Varför "Tools" är det fel mentala modellen

Standardformatet för MCP är:

• "Exposa metoder som verktyg
• "Låt modellen välja vilket verktyg man ska ringa
• "Ansök tillstånd innan man sätter igång

Detta misslyckas av förutsägbara anledningar:

1. verktygsbeschreibunger blir prompter: LLM drar slutsatsen om mening från ordspråket , inte från schemasemantik
2. Vad händer när man väljer ett verktyg?: Modellet optimerar för trovärdighet , inte korrekthet M SK2 och väljer verktyg baserat på beskrywings likheter
3. Tillåtelseproppar är UX, inte säkerhets: En modaldialog hindrar inte att det felaktiga verktyget ska väljas
4. Ingen återspelbarhet: Du kan inte reproducera en sessie eftersom verktygsvalet var sannolikhetsmässigt

Reframställa: MCP slutpunkter publicerar signaler

• Signaler är skrivna, begränsade , och antagliga
• Varje signal har tillförlitlighet, ,, provenance och bevispunkter.
• Naturspråk är ett presentationslayer, inte substratet

flowchart LR
    subgraph Wrong["❌ Tools Mental Model"]
        Desc[Tool Description<br/>'Gets weather for city'] --> LLM1[LLM Chooses]
        LLM1 --> Execute[Execute Action]
        Execute --> Trust1[Trust Result?]
    end

    subgraph Right["✓ Signals Mental Model"]
        Schema2[Typed Schema<br/>city: string, units: enum] --> Invoke2[Deterministic Invoke]
        Invoke2 --> Signal[Signal Response<br/>+ confidence + provenance]
        Signal --> Validate2[Constrainer Validates]
    end

    style Wrong fill:none,stroke:#dc2626,stroke-width:2px
    style Right fill:none,stroke:#16a34a,stroke-width:2px
    style Desc fill:none,stroke:#dc2626,stroke-width:2px
    style LLM1 fill:none,stroke:#dc2626,stroke-width:2px
    style Execute fill:none,stroke:#dc2626,stroke-width:2px
    style Trust1 fill:none,stroke:#dc2626,stroke-width:2px
    style Schema2 fill:none,stroke:#16a34a,stroke-width:2px
    style Invoke2 fill:none,stroke:#16a34a,stroke-width:2px
    style Signal fill:none,stroke:#16a34a,stroke-width:2px
    style Validate2 fill:none,stroke:#16a34a,stroke-width:2px

Signalkontrakt över chat

Varje MCP slutpunkt i mina system har:

• En schema: Tiktade in- och utgångar , inte gratis
• Förtroende: Hur säker är detta resultat
• Förekomst: Var kom detta ifrån?
• Evidensspetsar: Vad kan kontrolleras oberoende av varandra

Inget gratis-textberättigande . Nej " bästa ansträngning

exempel från produktionssystem:

Regelen: Om ett resultat inte kan valideras, så är det inte accepterat.

Detta är samma princip som Designregler #5: fakta behöver bevis

The Constrainer: Den del som alla hoppar över

De flesta MCP-lektioner visar:

1. Definiera verktyg
2. Koppla till LLM
3. Låt det köra

Den saknande komponenten är konstrainer - den deterministiska logiken som

• Bedömer konkurrensutsatta förslag
• Inspekterar policy
• Bestämdar vad som förblir och vad som avfärdas
• Rötter till eskalation när självförtroende är låg

flowchart TD
    subgraph Sources["Signal Sources"]
        Heuristics[Heuristics<br/>Text-likeliness: 0.3]
        LocalModel[Local Model<br/>Florence-2 OCR: 0.85]
        LLMCall[LLM Escalation<br/>GPT-4V: 0.92]
    end

    subgraph Constrainer["Constrainer Logic"]
        Receive[Receive All Signals]
        Check{Confidence<br/>≥ 0.7?}
        Cross[Cross-Validate<br/>Signals Agree?]
        Accept[Accept as Fact]
        Reject[Reject / Log]
        Escalate[Escalate to<br/>Higher Tier]
    end

    Heuristics --> Receive
    LocalModel --> Receive
    LLMCall --> Receive

    Receive --> Check
    Check -->|Yes| Cross
    Check -->|No| Escalate
    Cross -->|Yes| Accept
    Cross -->|No| Reject

    style Sources fill:none,stroke:#d97706,stroke-width:2px
    style Constrainer fill:none,stroke:#2563eb,stroke-width:2px
    style Heuristics fill:none,stroke:#d97706,stroke-width:2px
    style LocalModel fill:none,stroke:#d97706,stroke-width:2px
    style LLMCall fill:none,stroke:#d97706,stroke-width:2px
    style Receive fill:none,stroke:#2563eb,stroke-width:2px
    style Check fill:none,stroke:#2563eb,stroke-width:2px
    style Cross fill:none,stroke:#2563eb,stroke-width:2px
    style Accept fill:none,stroke:#16a34a,stroke-width:2px
    style Reject fill:none,stroke:#dc2626,stroke-width:2px
    style Escalate fill:none,stroke:#7c3aed,stroke-width:2px

Verkliga konstrainer beslut:

• Avfärda LLM-caption när heuristiken inte håller med om text
• Preferera lägret-förtroende men bevisad OCR jämfört med högt -för troende hallucinaerade text
• Flytta till syn LLM bara när den lokala modellförtroendet är uppfylld < 0.7

MCP kopplar samman komponenter

Att stänga av LLM. ( Och varför gör jag det?

Mina MCP-server fungerar fortfarande med den deaktiverade LLM

Det här är "'", det är inte en nedgraderad mode , .", primära mode.

Om ditt system slutar fungera när LLM inte är tillgängligt,

Kernfunktionen:

• Deterministisk sammanfattning av utlägsna fakta
• Evidence-first sökning via inbäddar och filter
• Strukturerade frågor mot faktadatabasen

LLM blir ":".

• Ett syntetiskt lager (optionellt)
• En förklaringsmotor ( när uppgefordert )
• En förstärkare ( för språkets utgångsnivå)

LLM är inte:

• En beslutsfattare
• minne
• En sanningsmotor

flowchart TD
    subgraph AlwaysOn["Always On (Deterministic)"]
        Sensors[Sensors + Heuristics]
        Local[Local Models<br/>Florence-2, Whisper, CLIP]
        Facts[(Facts Database)]
        Query[Query Engine]
    end

    subgraph Optional["Optional (LLM)"]
        Synthesis[Natural Language Synthesis]
        Explain[Explanation Generation]
    end

    Sensors --> Local
    Local --> Facts
    Facts --> Query
    Query --> Synthesis
    Query --> Explain

    style AlwaysOn fill:none,stroke:#16a34a,stroke-width:2px
    style Optional fill:none,stroke:#6b7280,stroke-width:2px,stroke-dasharray: 5 5
    style Sensors fill:none,stroke:#16a34a,stroke-width:2px
    style Local fill:none,stroke:#16a34a,stroke-width:2px
    style Facts fill:none,stroke:#16a34a,stroke-width:3px
    style Query fill:none,stroke:#16a34a,stroke-width:2px
    style Synthesis fill:none,stroke:#6b7280,stroke-width:2px
    style Explain fill:none,stroke:#6b7280,stroke-width:2px

Varför är detta viktigt:

MCP som en gräns, Inte en integrering

Jag behandlar MCP som en hårt gräns:

• Proses isolering: MCP-server körs i separata processer
• Otydliga ingångar / utgångar: Ingen delad mutable tillstånd
• Ingen omgivning: Varje sändning bedöms på explicita ingångar
• Inskrivna kontrakt: Schemaöverträdelser är fel

Detta kontrasterar med:

• In-processagenter med gemensam minne
• Prompt-komma med dolda kontextaccumulationer
• "Konversationsmässigt " användandet av verktyg där tidigare vridningar påverkar beteendet

Varför är gränser viktiga:

1. Spela om: Reproduera vilken sessie som helst genom att spela in inputs igen
2. Revidering: Varje signal har en spårbar ursprung
3. Deterministisk test: Samma ingångar → samma utgångar
4. Hållbarhet: Betydande beslutskedja

flowchart LR
    subgraph Process1["Process: Orchestrator"]
        Orch[Orchestrator<br/>Constrainer Logic]
    end

    subgraph Process2["Process: MCP Server 1"]
        MCP1[Image Analysis<br/>Signals]
    end

    subgraph Process3["Process: MCP Server 2"]
        MCP2[Audio Analysis<br/>Signals]
    end

    subgraph Process4["Process: MCP Server 3"]
        MCP3[Video Analysis<br/>Signals]
    end

    Orch <-->|MCP Protocol| MCP1
    Orch <-->|MCP Protocol| MCP2
    Orch <-->|MCP Protocol| MCP3

    style Process1 fill:none,stroke:#2563eb,stroke-width:2px
    style Process2 fill:none,stroke:#16a34a,stroke-width:2px
    style Process3 fill:none,stroke:#16a34a,stroke-width:2px
    style Process4 fill:none,stroke:#16a34a,stroke-width:2px
    style Orch fill:none,stroke:#2563eb,stroke-width:2px
    style MCP1 fill:none,stroke:#16a34a,stroke-width:2px
    style MCP2 fill:none,stroke:#16a34a,stroke-width:2px
    style MCP3 fill:none,stroke:#16a34a,stroke-width:2px

Misslyckande sätt MCP exempel Don't prata om

Verkliga misslyckanden från obegränsad MCP-användning:

Den vanliga threaden: dessa misslyckanden händer eftersom LLM är tilltrolig som en auktoritet.

Fixen: LLMs föreslår att ",", Constrainers decide , och ",", fakta förblir.

Vad är MCP bra på? ( När det används ordentligt)

MCP är utmärkt för:

• Kapacitetsforskning: Runtimeberäkning av tillgängliga signaler
• Inter-processkomposition: Klara gränser mellan komponenterna
• Interoperabilitet med verktyg: Fungerar med vilken MCP-client som helst
• Modell-agnostisk integrering: Swap LLMs utan att ändra signalkontrakt

MCP är inte:

• En agent ram
• Ett resonemangssystem
• En säkerhetslag
• En gräns för tro

Använd MCP för vad det är

Var MCP stannar

MCP standardiserar hur modeller och verktyg utbyter sammanhang. Det definierar inte vem som är tillåten att agera

Det finns andra sätt att formalisera dessa begränsningar. ( som ibland beskrivs som handlingskapacitetsprotokoll.

Den här artikeln handlar inte om AKP, utan om designprincipen. transporter och styrning är separata problem.

MCP säger till dig hur att ringa ett verktyg. Något annat måste bestämma om du borde, i mina system, att, i företagssystemen, kanske det är en policymotor.

Demo MCP vs Production MCP

Slutning

MCP gör det möjligt sammansättning. Determinism gör det möjligt tillit. LLMs gör det möjligt skicklighet.

Men bara om:

sannolikheten föreslår — och determinismen förblir kvar

MCP utan konstrainer är bara en snabb injiction med extra steg.

Gör syntekniken till det sista steget. Gör LLM till en optional variant. Gör varje fakta spårbar

Nyckelbegrepp

• MCP (Modella Kontextprotokoll: Kabelprotokoll för verktygsforskning och invocation mellan processer
• Konstruenter: Deterministisk logik som utvärderar förslag och bestämmer vad som förblir kvar
• Signal: Typad respons med självförtroende , provenance
• Förespråkare: Alla komponenter | ( | LLM | , | Lokalmodell |, | Heuristik | ) | som antyder fakta utan att ha rätt
• Evidence pointer: referens till verifierbar källa

Related Articles

tidigare i serien: Del 1: Varför LLM misslyckas som sensorer

• Reduced RAG: Map-Reduzerad för Probabilistiska System
• ImageSummarizer: Begränsad fuzzy bildintelligens
• VideoSummarizer: Reduktion av RAG för video
• StyloFlow: Signal