Tools & connectors

A Vectara agent reaches the outside world through three integration shapes:

• Tools — the agent calls out during a turn (a Salesforce lookup, a SQL query, a price API). Outbound.
• Connectors — a third-party surface delivers a message to the agent (a Slack mention turns into a session). Inbound.
• Pipelines — data flows into a corpus on a schedule (S3, SharePoint, web, custom). Batch.

This page is the conceptual chapter on the outbound and inbound sides. For the batch (ingest) side, see Pipelines.

The integration economics

In most platforms, "we need to integrate with X" is a quarter-long project: a vendor SOW, a connector framework, a platform release. In Vectara, it's minutes to live for most cases and a few hours for the hard ones. Three things make that possible:

• A 35+ tool built-in catalog that already covers retrieval, corpus operations, documents, images, SQL, sandboxed compute, and orchestration.
• Two fast custom paths — Python Lambdas (sandboxed, no infrastructure) and MCP servers (any server you already run).
• A universal HTTP wrapper — web_get with OAuth handling — that turns any REST API into a typed agent tool with a few lines of JSON.

The connector model is your competitive answer to vendor lock-in. You're never waiting on a vendor's roadmap to add the integration you need.

Tools — how the agent acts outward

A tool is a small, named, schema-typed function the LLM can call. The agent's tool_configurations map lists what's available, and the LLM decides which to invoke based on the user's request.

Three sources fill that map:

1. The built-in catalog (35+ tools)

Vectara-managed tools that cover the common surfaces. List them in tool_configurations — no code to write.

Category	Built-in tools
Retrieval	corpora_search, web_search, web_get
Corpus operations	core_document_index, metadata_query, list_documents, get_document_text, corpus_filter_attribute_stats, corpora_list
Documents	document_analyze, document_conversion, document_chunking, merge_core_documents
Artifacts	artifact_create, artifact_read, artifact_grep, artifact_jq
Images / VLM	image_read, image_crop, image_resize, image_rotate, image_zoom
Data & compute	sql_query, sandbox_exec
Orchestration	sub_agent, invoke_skill, search_session_history
Slack	slack_post_message, slack_read_channel_history, slack_list_channels, slack_list_users

For the full catalog and per-tool reference, see Agent tools.

2. web_get — wrap any REST API

The fastest path to a custom outbound tool. web_get is a built-in HTTP fetcher that becomes a purpose-built API client when you give it a focused name, a tight description, locked-down argument_override, and an output transform.

"sf_create_lead": {
  "type": "web_get",
  "argument_override": {
    "method": "POST",
    "url": "https://your-org.my.salesforce.com/services/data/v60.0/sobjects/Lead",
    "headers": {
      "Authorization": { "$ref": "agent.secrets.sf_bearer" },
      "Content-Type": "application/json"
    }
  }
}

Auth is the one variable across integrations — agent.secrets for service accounts, session.secrets for per-user OAuth, header $ref for static bearers. Same shape, different fields. Three patterns cover every enterprise integration you've ever seen. The full playbook with copy-paste configs for Google Drive, GitHub, Salesforce, ServiceNow, and more lives in Connector authentication.

For the web_get reference (URL templating, output transforms, streaming, content limits), see web_get tool.

3. Lambda tools (Python, sandboxed)

For pure-Python business logic the catalog and web_get don't cover — validators, calculators, scorers, parsers, data shaping. POST the code, get a tool_id, attach to any agent.

POST /v2/tools
{
  "type": "lambda",
  "name": "score_lead",
  "language": "python",
  "code": "def process(industry: str, headcount: int) -> dict: ..."
}

Lambdas run sandboxed in the Vectara runtime. No infrastructure to provision. Limits: pure compute, no external network access (use web_get or MCP for outbound API calls).

For the configuration model, see Lambda tools.

4. MCP servers

Register any Model Context Protocol server URL with an auth token, and every tool that server exposes becomes callable by the agent. Same protocol Claude Desktop, Cursor, and the public MCP ecosystem already use.

"github": {
  "type": "mcp",
  "server_url": "https://mcp.example.com/github",
  "auth": { "token": { "$ref": "agent.secrets.gh_token" } }
}

Use cases: a server your team already runs, a vendor's MCP server, or one from the growing public ecosystem.

For the configuration model, see Model Context Protocol.

Three scoping mechanisms keep tools safe

• allowed_tools per step narrows the catalog at each state. Least privilege by default.
• argument_override locks specific tool arguments at config time. The LLM cannot see or modify them.
• $ref injects session-scoped values (user_id, tier, corpus_key, secrets) into tool arguments at call time, never into the prompt.

A prompt-injection attack against the LLM has nothing to exfiltrate and nowhere to escalate.

Picking the right tool path

The four paths in order of effort, cheapest first:

Need	Path	Time to live
It's already in the catalog	List it in tool_configurations	Minutes
There's already an MCP server	Register the URL	Minutes
Wrap a third-party REST API	web_get + argument_override + the right $ref for auth	Same day
Pure-Python business logic	Lambda tool	~1 hour

Pick the cheapest path that fits. The integration runs as a normal tool either way — the LLM doesn't care which path it came from.

Connectors — how third-party surfaces talk to the agent

A connector is the inverse of a tool. Instead of the agent reaching out, a third-party surface (Slack, soon others) delivers an event to the agent and the agent responds back through the same channel. The connector owns the webhook, the credentials, and the translation between the venue's message shape and an agent session.

Today the canonical connector is Slack. A Slack connector binds an agent to a Slack app and signing secret, exposes a webhook path under /v2/agents/{agent_key}/connectors/{connector_id}/input, and turns threads in your workspace into agent sessions.

Slack thread     →  Vectara webhook  →  Agent session
                                          ↓
Slack thread     ←  Agent response   ←  Streamed events

What that buys you:

• Bidirectional — the agent isn't just answering; it can post, read channel history, look up users.
• Threaded sessions — each Slack thread maps to its own session, with the conversation state preserved.
• Identity propagation — the Slack user's identity flows into session.metadata, and any corpora_search honors the same RBAC as your direct API calls.

For the configuration model, see Slack connectors. For other surfaces (Teams, Discord, custom webhooks), the connector model is extensible — tell us what you need.

Sub-agents — tools that are agents

A sub-agent is a full Vectara agent wrapped as a single tool. The parent calls it like any other tool. The called agent runs in its own session with its own steps, tools, and model.

This belongs to two stories at once:

• As composition — the workflow story. The same approvals sub-agent backs HR, procurement, and refunds. See Workflows.
• As an outbound tool — the agent is reaching "out" to a specialist. That specialist might wrap its own MCP server, lambda, or web_get calls.

For the configuration model, see Sub-agents.

Why this competitive shape matters

Most enterprise AI platforms ship with a fixed connector list. You wait for the vendor to add Wolken, or Confluence, or your internal ERP. The roadmap is theirs.

Vectara ships the integration mechanism, not just the integrations. The built-in catalog covers the common surfaces; the custom paths (Lambda, MCP, web_get) cover everything else. New tools live in minutes, not platform releases. The connector source code is yours, versioned with your application — whether your team writes it or Vectara Managed Agents builds it on your behalf.

That is the answer to vendor lock-in.

Related

• Agent anatomy: Tools — the place in the agent shape where tools attach.
• Workflows — how the agent decides when to call which tool.
• Agent tools — the built-in catalog reference.
• Lambda tools — the Python sandbox reference.
• Model Context Protocol — the MCP integration reference.
• web_get tool — the universal HTTP wrapper reference.
• Connector authentication — the three credential patterns side by side, with copy-paste configs.
• Slack connectors — the inbound Slack reference.
• Integrations overview — data sources, tools, connectors taxonomy.
• Pipelines — the batch ingestion side of the story.