AI / Agent Reference · Reference

Tool Calling

Tool calling is the broader paradigm of enabling AI agents to use external tools — functions, APIs, commands, and services — to extend their capabilities beyond pure text generation. Function calling is one mechanism for tool calling; Model Context Protocol (Model Context Protocol) is another. Model Context Protocol standardizes how AI applications connect to external tools and data sources. Components: Client: AI ap…

draftneeds-review0 source links5 resolved links

wiki/wiki/ai-ml/tool-calling.md

Answer

Auto-generated neutral summary from the source page — needs human review before trusted use.

Evidence & Source Cards

No explicit artifact, library, or external source links found in this sample slice. Evidence state remains needs-review.

Source Excerpt

Tool Calling vs Function Calling

Aspect	Function Calling	Tool Calling (Model Context Protocol)
Scope	Single API, tight integration	Multi-server, standardized protocol
Standard	Provider-specific (OpenAI, Anthropic)	Open protocol (Model Context Protocol)
Discovery	Hard-coded schemas	Dynamic tool discovery
Ecosystem	Limited to integrated functions	Growing third-party server ecosystem
Complexity	Simpler, direct	More infrastructure, more flexible

MCP (Model Context Protocol)

Model Context Protocol standardizes how AI applications connect to external tools and data sources.

Architecture

AI Client (Large Language Model app) ←→ Model Context Protocol Host ←→ Model Context Protocol Servers (tools, resources, prompts)

Components:

Client: AI application (Claude Desktop, Cursor, etc.)
Host: Middleware that manages server connections
Servers: Tool providers (filesystem, database, web search, custom tools)

Transport Layers

Transport	Use Case	Properties
stdio	Local tools	Simple, process-based, no network
SSE	Remote tools	Server-sent events, unidirectional
HTTP	API integration	Bidirectional, stateless

MCP Primitives

Tools: Executable functions with schemas. The server defines the tool, the client calls it.

{
  "name": "read_file",
  "description": "Read a file from the filesystem",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": { "type": "string" }
    }
  }
}

Resources: Readable data sources (files, database queries, API endpoints). Addressed by URI.

file:///path/to/file.txt
sqlite:///database.db?query=SELECT * FROM users

Prompts: Reusable prompt templates with parameters.

{name}: "summarize_file"
{description}: "Summarize the contents of a file"
{arguments}: [{ "name": "path", "description": "File path" }]

Tool Design Principles

Clarity

Single responsibility: Each tool does one thing well
Clear naming: read_file not rf or get_data
Descriptive descriptions: Explain what, when, and why

Reliability

Deterministic output: Same input → same output
Error handling: Clear error messages, not crashes
Idempotency: Safe to call multiple times

Security

Input validation: Validate all inputs
Output sanitization: Clean outputs before returning
Access control: Restrict tool access by user/context
Sandboxing: Run untrusted tools in isolated environments

Multi-Tool Orchestration

Parallel Execution

When tools are independent, execute in parallel:

Prompt → [Tool A, Tool B, Tool C] → Combine results → Response

Example: Research task — search web, read local files, query database simultaneously.

Sequential Execution

When tools depend on each other:

Prompt → Tool A → Tool B (uses A's result) → Tool C (uses B's result) → Response

Example: File processing — read file → parse content → summarize → save result.

Conditional Execution

Tool selection based on intermediate results:

Prompt → Tool A → If result matches X: Tool B, else: Tool C → Response

Rate Limiting and Throttling

Per-tool limits: Different tools have different rate limits
Global limits: Total tool calls per minute/hour
Backoff strategy: Exponential backoff on rate limit errors
Queue management: Prioritize urgent tool calls

Common Tool Categories

Filesystem

Read/write files, list directories, search files
Examples: read_file, write_file, search_files, list_directory

Database

Query databases, execute SQL, manage connections
Examples: query_database, execute_sql, list_tables

Web

Search the web, extract content, make HTTP requests
Examples: web_search, web_extract, http_request

Code Execution

Run code, execute scripts, manage environments
Examples: execute_python, run_shell_command, install_package

Communication

Send messages, manage emails, post to platforms
Examples: send_email, send_message, post_to_slack

Security Considerations

Tool Permissions

Least privilege: Each tool has minimum required permissions
User approval: Dangerous tools require explicit user consent
Audit logging: All tool calls logged for review

Input/Output Safety

Path traversal: Validate file paths, prevent directory escape
Command injection: Sanitize shell commands, use parameterized queries
Data exfiltration: Limit data returned by tools, filter sensitive content

Sandboxing

Container isolation: Run untrusted tools in containers
Resource limits: CPU, memory, network limits per tool
Network restrictions: Block outbound connections for local tools