Tool calling 2026: function calling, MCP, and real-world integration

[Aior]

Tool calling neden kritik?​

Modern LLM uygulamaları sadece metin üretmiyor — gerçek dünyada eylem alıyor. Tool calling (function calling), modelin bir aksiyonu (API çağrısı, database sorgusu, hesaplama) çalıştırmaya karar vermesi ve doğru parametrelerle iletmesi. AIOR projelerinde tool calling olmadan ciddi LLM uygulaması düşünmüyoruz; "chatbot ama gerçekten yararlı" kategorisinin temeli.

Function calling — Anthropic ve OpenAI tarafı​

Hem Claude (Anthropic) hem GPT (OpenAI) function calling'i native destekliyor. Provider'a fonksiyon schema (JSON) ile tanımlanır:

{
  "name": "get_customer_invoice",
  "description": "Müşterinin son faturalarını çeker",
  "input_schema": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "limit": {"type": "integer", "default": 5}
    },
    "required": ["customer_id"]
  }
}

Model uygun bağlamda bu fonksiyonu "çağırır" (parametre listesi döner), uygulama gerçek API çağrısını yapar, sonucu modele geri besler, model final yanıtı üretir.

MCP (Model Context Protocol) — 2024 sonrası gelişim​

MCP, Anthropic'in açık kaynak protokolü olarak başlatıldı. LLM'lerin dış sistemlerle (database, API, file system) standart şekilde iletişim kurmasını sağlar. 2026'da MCP yaygın benimsendi — Claude Desktop, IDE entegrasyonları, custom uygulamalar.

AIOR projelerinde MCP'yi tercih ettiğimiz durumlar:

• Birden fazla LLM provider ile çalışan uygulamalar — kod paylaşımı.
• Standart araç ekosisteminden faydalanma (GitHub MCP, Slack MCP, Postgres MCP).
• Sub-process'leri tool olarak expose etme.

Tool design — granular vs coarse​

Tool'lar nasıl boyutlandırılmalı? AIOR'da uyguladığımız desen:

• Granular tools — "get_customer_name", "get_customer_email" tek tek. Model'in fazla call yapması gerekir, ama her tool'un test'i ve mockup'ı kolay.
• Coarse tools — "get_customer_profile" tek call'da hepsi. Model'in karar yükü düşer, ama tool implementation karmaşıklaşır.

Pratik orta yol: kullanım frequency'sine göre boyutla. Sık birlikte istenen veriler tek tool'da, nadiren gereken ayrı.

Parameter validation​

LLM her zaman doğru parametre üretmez. AIOR'da tool implementation'larda validation katmanları:

• JSON schema validation — yapı kontrolü.
• Type coercion ve normalization.
• Range check'leri (örn. limit > 100 reddedilir).
• Authorization check — bu kullanıcı bu tool'u kullanabilir mi?
• Rate limiting — kullanıcı bir API'yi spam edemez.

Error handling — model'e nasıl raporlanır?​

Tool call failure halinde model'e raporlanan format kritik. AIOR'da tutarlı error response:

{
  "error": true,
  "error_type": "not_found|permission_denied|rate_limited|server_error",
  "message": "Kullanıcı dostu hata açıklaması",
  "suggestion": "Modele ne yapması gerektiği önerisi"
}

Bu yapı modele recovery yolunu açıyor; örneğin "not_found" gelince model alternative arama önerebiliyor.

Multi-tool orchestration​

Karmaşık görevler birden fazla tool'un sıralı veya paralel kullanımını gerektirebilir. Modern LLM'ler bunu native destekliyor (parallel tool use). AIOR projelerinde:

• Müşteri sorusu için context fetch (3 paralel tool).
• Context'le birlikte ana akıl yürütme.
• Action gerekiyorsa update tool çağırma.
• Confirmation user'a göster.

Observability — tool call izleme​

Production tool calling'i loglamadan kullanmak risk. Her tool call için AIOR'ın log şeması:

• Session ID, user ID.
• Tool adı, parametreler (sensitive data masked).
• Latency (model + tool execution + total).
• Success/failure status.
• Error detail (varsa).
• Token cost.

Bu log'lar sorun gidermede ve maliyet analizinde kritik.

Security kaygıları​

Tool calling LLM'e gerçek sistem erişimi veriyor; risk profili artıyor:

• Prompt injection ile destructive tool tetiklenebilir mi?
• Authorization check'leri tool seviyesinde uygulanmalı (sadece system prompt'a güvenme).
• Destructive action'larda human-in-the-loop (delete, write için onay iste).
• Audit log — kim ne zaman hangi tool'u çağırdı.

AIOR projelerinde destructive tool'ları her zaman confirmation step ile sınırlandırıyoruz.

Test stratejisi​

Tool calling test'i çok katmanlı:

• Unit test — tool implementation izole.
• Mock LLM ile integration test — model çağrılarını mock'la, tool akışı doğrula.
• Real LLM ile e2e test — production-benzeri akış.
• Adversarial test — prompt injection ile tool misuse denenir.

Sonuç​

Tool calling 2026'da LLM uygulamalarının gerçek değer üretici katmanı. Doğru tool granularity, sıkı validation, structured error handling ve security disiplini ile production-grade uygulamalar üretilebilir. AIOR olarak müşteri LLM projelerinde tool calling infrastructure'ını standart paket halinde teslim ediyoruz. Sizin tarafınızda MCP kullanıyor musunuz, yoksa provider-specific function calling mı?

Why is tool calling critical?​

Modern LLM applications don't just generate text — they take action in the real world. Tool calling (function calling) is the model deciding to execute an action (API call, DB query, computation) and passing the right parameters. AIOR doesn't consider serious LLM applications without tool calling; it's the foundation of "chatbot but actually useful."

Function calling — Anthropic and OpenAI side​

Both Claude (Anthropic) and GPT (OpenAI) support function calling natively. Functions are defined to the provider via JSON schema:

{
  "name": "get_customer_invoice",
  "description": "Fetches customer's recent invoices",
  "input_schema": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "limit": {"type": "integer", "default": 5}
    },
    "required": ["customer_id"]
  }
}

In appropriate context, the model "calls" this function (returns the parameter list), the application makes the real API call, feeds the result back to the model, and the model produces the final response.

MCP (Model Context Protocol) — development since 2024​

MCP started as Anthropic's open-source protocol. It lets LLMs communicate with external systems (databases, APIs, file systems) in a standard way. MCP is widely adopted in 2026 — Claude Desktop, IDE integrations, custom apps.

Cases where AIOR picks MCP:

• Applications working with multiple LLM providers — code sharing.
• Leveraging the standard tool ecosystem (GitHub MCP, Slack MCP, Postgres MCP).
• Exposing sub-processes as tools.

Tool design — granular vs coarse​

How should tools be sized? The pattern we apply at AIOR:

• Granular tools — "get_customer_name", "get_customer_email" separately. The model needs to make more calls, but each tool is easy to test and mock.
• Coarse tools — "get_customer_profile" gets all in one call. Less decision load for the model, but tool implementation gets complex.

Practical middle path: size by usage frequency. Often-requested-together data in one tool; rare ones separate.

Parameter validation​

The LLM doesn't always produce correct parameters. Validation layers in our tool implementations:

• JSON schema validation — structure check.
• Type coercion and normalisation.
• Range checks (e.g. reject limit > 100).
• Authorization check — can this user use this tool?
• Rate limiting — user can't spam an API.

Error handling — how to report to the model?​

On tool-call failure, the format reported to the model is critical. AIOR's consistent error response:

{
  "error": true,
  "error_type": "not_found|permission_denied|rate_limited|server_error",
  "message": "User-friendly error description",
  "suggestion": "Suggestion to the model on what to do"
}

This structure gives the model a recovery path; e.g. on "not_found" the model can suggest an alternative search.

Multi-tool orchestration​

Complex tasks may require sequential or parallel use of multiple tools. Modern LLMs support this natively (parallel tool use). On AIOR projects:

• Context fetch for a customer question (3 parallel tools).
• Main reasoning with the context.
• If an action is required, call an update tool.
• Show confirmation to the user.

Observability — tracking tool calls​

Using tool calling in production without logging is risky. AIOR's log schema per tool call:

• Session ID, user ID.
• Tool name, parameters (sensitive data masked).
• Latency (model + tool execution + total).
• Success/failure status.
• Error detail (if any).
• Token cost.

These logs are critical in troubleshooting and cost analysis.

Security concerns​

Tool calling gives the LLM real system access; the risk profile rises:

• Can prompt injection trigger a destructive tool?
• Authorization checks must be applied at the tool level (don't trust the system prompt alone).
• Human-in-the-loop on destructive actions (ask for confirmation on delete, write).
• Audit log — who called which tool when.

On AIOR projects, destructive tools are always gated by a confirmation step.

Test strategy​

Tool calling testing is multi-layered:

• Unit test — tool implementation isolated.
• Integration test with mock LLM — mock model calls, verify tool flow.
• E2E test with real LLM — production-like flow.
• Adversarial test — try tool misuse via prompt injection.

Bottom line​

Tool calling in 2026 is the value-producing layer of LLM applications. With proper tool granularity, strict validation, structured error handling, and security discipline, production-grade applications become possible. AIOR delivers tool calling infrastructure as a standard package on customer LLM projects. Are you using MCP, or provider-specific function calling?