Ce este MCP? Cum se acceseaza LLM-urile prin MCP? Cum funcționează autorizarea MCP? și alte aspecte

MCP arată ca o cheie de Aur pentru a debloca întregul potențial al LLM-urilor. De la Google la Microsoft (MCP pe Windows 11) și multe între ele. Model Context Protocol — MCP atrage mult hype și pare supra-licitat. Are deja câteva starturi false, cum ar fi SSE (care este depreciat în favoarea HTTP Streaming din cauza costului de găzduire în cloud).

Cu toate acestea, MCP umple un gol pentru integrarea LLM cu apeluri API și este suficient de popular pentru a deveni singurul standard care le guvernează pe toate. Este pur și simplu o modalitate de a vă publica API-urile, cum ar fi prin Swagger, astfel încât LLM-urile să le poată înțelege și să poată genera invocări ale API-ului cu argumente; aproape ca REST; doar că acesta este prin JSON-RPC și este independent de transport, spre deosebire de REST sau Protobuf/gRPC, care se bazează pe HTTP.

Cu toate acestea, toate serverele MCP de la distanță sunt bazate pe HTTP, în timp ce cele locale comunică prin conducte numite de intrare/ieșire standard STDIO.

MCP cu un exemplu de simplu Calculator MCP Server

Modelele de limbaj mari (LLM-uri) sunt foarte puternice – dar nu sunt concepute pentru a fi calculatoare. Ele se luptă adesea cu operații aritmetice precise sau logice grele.

Deci, dacă în loc să-i forțăm să calculeze, le-am oferi instrumentul potrivit ori de câte ori se confruntă cu o sarcină de calcul?

Această idee nu este nouă. A fost deja implementat în multe feluri. Pornind de la codul generat de LLM pentru a face calculele și apoi extragerea acelui cod și rularea acestuia într-un sandbox python și oferirea rezultatului; sau LLM generând URL-ul sau JSON pentru apelarea unui alt serviciu prin REST sau GRPC și apoi extragerea URL-ului sau JSON și invocarea serviciului și obținerea rezultatului; sau poate într-un alt mod mai complicat de atat.

Cu MCP, acest apel de instrument este standardizat. Se bazează pe JSON-RPC.

Are două variante; (1) uneltele locale pot fi apelate prin STDIO (pipes). (2) Unelte de la distanță prin HTTP.

Un mod simplificat de a gândi MCP prin HTTP este că este aproape ca in cazul REST API. Dar cea mai mare diferență este că REST este stateless, în timp ce MCP este stateful. Și asta influentează o mulțime de decizii de proiectare.

MCP este un concept simplu pe care chiar și oamenii non-tehnici îl pot înțelege.

Am găzduit un server MCP simplu în Python în mod liber prin HuggingFace Spaces folosind Docker. Specificația MCP este complexă și aveți nevoie de un framework precum FastMCP pentru a construi serverul pentru Python.

from fastmcp import FastMCP
mcp = FastMCP()
# Să presupunem că acesta este instrumentul pe care doriți să-l expuneți
# Treceti toate tipurile și descrierea lor
@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers"""
    return a + b
if __name__ == "__main__":
    # take host and port from command line
    import argparse
    parser = argparse.ArgumentParser(description="Run FastMCP server")
    parser.add_argument("--host", type=str, default="0.0.0.0", help="Host address (default: 0.0.0.0)")
    parser.add_argument("--port", type=int, default=7860, help="Port number (default: 7860)")
    args = parser.parse_args()
    mcp.run(
        transport="streamable-http", # https://github.com/modelcontextprotocol/python-sdk/?tab=readme-ov-file#streamable-http-transport
        host=args.host,
        port=args.port,
        path="/mcp",
        log_level="debug",
    )

Se expune metoda add

Am facut si un client MCP găzduit prin Colab, pe care ar trebui să-l puteți rula și testa.

Este mai ușor de inteles fluxul pe partea de client. În primul rând, ne conectăm la serverul MCP și îi cerem să listeze instrumentele.

async with Client("https://alexcpn-mcpserver-demo.hf.space/mcp/") as client:
        await client.ping()
        # List available tools
        tools = await client.list_tools()
        print("Available tools:", tools)
        tool_result = await client.call_tool("add", {"a": "1", "b": "2"})
        print("Tool result:", tool_result)

Rezultatul este următorul.

Available tools: [Tool(name='add', description='Add two numbers', inputSchema={'properties': {'a': {'title': 'A', 'type': 'integer'}, 'b': {'title': 'B', 'type': 'integer'}}, 'required': ['a', 'b'], 'type': 'object'}, annotations=None)]

Fără un framework, acesta este modul în care expunem detaliile instrumentului pe server și este posibil să fi observat că asta este ceea ce primește Clientul. Framework-uri precum FastMCP deduc acest lucru din tipul informațiilor.

@app.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="add",
            description=(
                "add two numbers and return the result. "
                
            ),
            inputSchema={
                "type": "object",
                "required": ["a", "b"],
                "properties": {
                    "a": {
                        "type": "integer",
                        "description": "The first number to add",
                    },
                    "b": {
                        "type": "integer",
                        "description": "The second number to add",
...

Apoi, dăm această ieșire „tool_result” LLM-ului și îi cerem să genereze o ieșire JSON adecvată pentru apelul instrumentului cu argumentele relevante.

a = 123124522
b= 865734234
question = f"Using the tools available {tool_result} frame the JSON RPC call to the tool add with a={a} and b={b}, do not add anything else to the output" + \
    "here is the JSON RPC call format {{\"method\": \"<method name>\", \"params\": {{\"<param 1 name>\": {<param 1 value>}, \"<param 2 name>\": {<param 2 value>} etc }}}}"

# Use a simple model like gpt-3.5-turbo
  completion = openai_client.chat.completions.create(
      model="gpt-3.5-turbo", messages=[
         {"role": "user", "content":question }
      ]
  )
  # Print the response
  print("LLM response:", tool_call)
  print(tool_call["method"], tool_call["params"])

Am obtinut JSON-ul de mai jos:

LLM response: {'method': 'add', 'params': {'a': 123124522, 'b': 865734234}}
add {'a': 123124522, 'b': 865734234}

Trimitem acest JSON către serverul LLM prin API-ul de apel al instrumentului MCP Client.

tool_result = await client.call_tool(tool_call["method"], tool_call["params"])
print("Tool result:", tool_result)

Rezultatul de la serverul MCP este mai jos.

Tool result: [TextContent(type='text', text='988858756', annotations=None)]

Simplu si corect – LLM apelează un instrument – mai degrabă LLM obține informații despre un instrument și generează semnătura de apel în format JSON, iar programul nostru folosește clientul MCP pentru a apela efectiv serverul MCP.

Autorizarea în MCP

MCP utilizează fluxul OAuth2 pentru autorizare. Aceasta înseamnă că nu trebuie să vă partajați numele de utilizator și/sau parola cu niciun client MCP. MCP Client vă redirecționează către serverul de resurse, să zicem un magazin foto sau Gmail sau orice alt serviciu, și vă conectați la server cu datele de conectare.

1. Client MCP –> să spunem Gmail MCP Server (stabiliți o conexiune nesigură)
2. Solicitați login(), serverul MCP trimite un link pentru a face clic cu sessionid-ul de mai sus
3. Utilizatorul face clic pe link (sau browserul se deschide cu linkul) la serverul Gmail
4. Utilizatorul introduce acreditările Gmail și i se arată că este conectat
5. Intern, serverele Gmail apelează serverul Gmail MCP cu ID-ul sesiunii (roșu și îi spune serverului MCP că ID-ul sesiunii este autentificat
6. Acum MCP Client –> sesiunea MCP Server este autentificată
7. Alte apeluri care au nevoie de autentificare nu au nevoie de niciun token sau cheie secretă, clientul MCP poate solicita utilizatorilor e-mailuri etc

Odată autentificat, serverul MCP primește un apel invers de la serverul de resurse, să zicem Gmail, prin adresa URL de redirecționare și marchează intern că sesiunea SSE sau HTTP Streaming este autentificată. Restul apelurilor pot fi apoi procesate fiind autentificate.

sursa: blog.mersi.ai