Inquir Compute · AI agents

AI agent tools API: authenticated serverless endpoints for LLM tools

Give each LLM tool its own authenticated HTTP endpoint behind the gateway: API key auth enforced before the handler runs, secrets injected from the workspace, isolated containers per tool, and warm pools for steady model traffic. One function per tool—small, testable, observable.

Last updated: 2026-10-11

Direct answer

AI agent tools API: authenticated serverless endpoints for LLM tools. Deploy each tool as a separate serverless function behind the API gateway. The gateway enforces API key auth before the handler code runs—no auth boilerplate per function. Secrets are scoped to the workspace and injected as environment variables at runtime.

When it fits

  • Production agents with multiple tools that need auth, isolated secrets, and per-tool observability
  • Mixed-language tool backends: Python for ML, Node.js for API calls
  • LLM apps using OpenAI function calling, Anthropic tool use, or Gemini function declarations

Tradeoffs

  • One server hosting all tools means one dependency failure (e.g. numpy version conflict) can take down every tool simultaneously. One deploy touches every capability.
  • Shared API keys across tools mean rotating one credential affects unrelated tools. A single auth layer for all tools means you cannot scope permissions per tool.

What LLM tool backends need

  • Authenticated HTTP endpoints — model cannot call open routes
  • Secrets off the model path — API keys never in prompts or context windows
  • Isolated execution — one tool failure cannot contaminate another
  • Low latency on the warm path — tight tool loops need sub-100ms response
  • Observability — trace which tool failed and why, per model call

Most agent demos inline all tool logic in one server or Lambda. When you move to production, you need each tool isolated, each secret scoped, and each failure traceable independently.

Why monolithic tool backends break in production

One server hosting all tools means one dependency failure (e.g. numpy version conflict) can take down every tool simultaneously. One deploy touches every capability.

Shared API keys across tools mean rotating one credential affects unrelated tools. A single auth layer for all tools means you cannot scope permissions per tool.

One function per tool, one gateway for all

Deploy each tool as a separate serverless function behind the API gateway. The gateway enforces API key auth before the handler code runs—no auth boilerplate per function. Secrets are scoped to the workspace and injected as environment variables at runtime.

Warm containers keep tool endpoints responsive for steady agent traffic—though the first deploy or idle-evicted container can still be cold, so set timeouts appropriately for the tools that matter most. Different tools use different runtimes: Node.js for API calls, Python for ML inference, Go for high-throughput lookups. For the overall agent architecture, see /serverless-for-ai-agents.

AI agent tools API features

Gateway-level API key auth

Per-route auth (none, X-Api-Key, or bearer) runs before your function code. Keys are 32-byte base64url, stored as SHA-256, shown once; scope a route to specific key IDs and rotate without touching handler code.

Per-tool secrets

Bind workspace secrets per function. The OpenAI key for the summarizer never reaches the database connector tool.

Isolated containers

Each tool runs in its own container. A broken dependency in one tool does not affect others.

Warm pools for tool loops

Enable warm containers for tools the model calls repeatedly. Measure p95 latency under realistic agent traffic before tuning pool size.

How to build an AI agent tools API on Inquir

1

Define tool contracts

Document input schema, output schema, and error shapes per tool. Keep contracts stable across model versions.

2

Deploy one function per tool

Node.js, Python, or Go—choose per tool based on library requirements. Bind secrets at the workspace level.

3

Wire gateway routes with API key auth

Create a route per tool endpoint. Enable API key auth at the route level. Share the API key with your orchestrator via secrets.

Tool API: lookup (Node.js), classify (Python), and the orchestrator dispatch

Same gateway, different runtimes. The orchestrator maps each tool_call from the model to a gateway route and calls it with one API key; secrets are scoped per function.

tools/lookup.mjs (Node.js — calls internal DB)
export async function handler(event) {
  // API key verified at gateway — handler assumes authenticated caller
  const { customerId } = JSON.parse(event.body || '{}');
  if (!customerId) return { statusCode: 400, body: JSON.stringify({ error: 'customerId required' }) };
  const record = await db.customers.findById(customerId); // DB_URL from workspace secrets
  if (!record) return { statusCode: 404, body: JSON.stringify({ error: 'not found' }) };
  return { statusCode: 200, body: JSON.stringify({ customer: record }) };
}
tools/classify.py (Python — calls OpenAI)
import json, os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])  # scoped to this tool only

def handler(event, context):
    body = json.loads(event.get("body") or "{}")
    text = body.get("text")
    if not text:
        return {"statusCode": 400, "body": json.dumps({"error": "text required"})}
    r = client.chat.completions.create(model="gpt-4o-mini",
        messages=[{"role": "user", "content": f"Classify intent: {text}"}])
    return {"statusCode": 200, "body": json.dumps({"intent": r.choices[0].message.content})}
orchestrator/dispatch.mjs (model tool_call → gateway)
// When the model returns a tool_call, dispatch it to the matching gateway route
const ROUTES = {
  lookup_customer: process.env.GATEWAY_URL + '/tools/lookup',
  classify_intent: process.env.GATEWAY_URL + '/tools/classify',
};

export async function dispatchToolCall(toolCall) {
  const { name, arguments: args } = toolCall.function ?? toolCall;
  const url = ROUTES[name];
  if (!url) return { error: `Unknown tool: ${name}` }; // returned to the model as the tool result
  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'X-Api-Key': process.env.TOOLS_API_KEY },
    body: typeof args === 'string' ? args : JSON.stringify(args),
  });
  return res.json(); // structured JSON (result or error) goes back to the model
}

Best fit for AI agent tools API

When this works

  • Production agents with multiple tools that need auth, isolated secrets, and per-tool observability
  • Mixed-language tool backends: Python for ML, Node.js for API calls
  • LLM apps using OpenAI function calling, Anthropic tool use, or Gemini function declarations

When to skip it

  • Single-tool demos that do not need auth or secret isolation

FAQ

Can the model discover tool routes automatically?

Return an OpenAPI spec or tool manifest from a discovery endpoint. The gateway routes the model to individual tool functions automatically once wired.

How do I handle tool versioning?

Use path prefixes (/tools/v1/lookup, /tools/v2/lookup) and route both to different function versions. Roll forward when the model is retested against the new contract.

How do I handle tool call errors?

Return a structured error JSON from the tool handler and pass it back to the model as the tool result—let the model decide whether to retry, ask for clarification, or give up.

What about tools that take longer than one model turn?

Have the handler enqueue a background job and return a job ID right away. The orchestrator polls a status route or waits for a callback, and the job retries failed work with backoff.