Tools
Seclai provides built-in tools that AI agents can call during Prompt Call steps. When enabled, tool definitions are injected into the model's prompt as function-calling schemas, allowing the model to call them during generation, inspect the results, and call more tools before producing its final response.
All tools — including web search and web fetch — are provided by the Seclai platform, not by the model vendor. This means every model that supports function calling gets access to web search, knowledge base retrieval, content inspection, and memory tools, regardless of whether the vendor offers those capabilities natively.
Tools are enabled per prompt step in the agent editor. Select the tool groups you want available in the Tools dropdown when configuring a prompt call step.
Tools vs. Explicit Steps
Seclai offers two ways to perform the same action — as an explicit agent step in the pipeline, or as a tool the model can call inside a prompt call step. Understanding the tradeoff helps you build agents that are both reliable and flexible.
Explicit Steps (Deterministic)
Explicit steps run as fixed stages in the agent pipeline. They execute unconditionally (or conditionally via a Gate) with parameters you define at design time.
Example — Summarize a specific webpage every morning:
- Web Fetch → fetch
https://example.com/daily-report - Prompt Call → "Summarize this report in 3 bullet points"
- Send Email → deliver the summary
Every run fetches the same URL, processes it the same way, and delivers the result. The pipeline is predictable and easy to debug.
Pros:
- Predictable — Each step runs in a fixed order with known inputs and outputs. Easy to trace and debug.
- Cheaper — No extra tokens spent on tool-calling overhead. The model only processes the content it receives.
- Works with any model — Doesn't require function-calling support.
- Easier to test — You can inspect each step's output individually in the trace.
Cons:
- Rigid — The pipeline always does the same thing regardless of context. You can't adapt the flow based on what the model finds.
- Requires upfront knowledge — You must know the exact URLs, queries, knowledge bases, or memory keys at design time (or derive them from metadata templates).
Tool-Enabled Prompt Calls (Autonomous)
When you enable tool groups on a prompt call step, the model decides which tools to call, how many times, and in what order. The model can search, read results, refine its approach, and call more tools — all within a single step.
Example — Research agent that answers arbitrary questions:
- Prompt Call with
seclai_web_tools+seclai_knowledge_base→ "Answer the user's question using web search and our internal knowledge base. Cite your sources." - Display Result → show the answer
The model autonomously decides whether to search the web, query the knowledge base, or both. It can issue multiple searches, follow up on partial results, and synthesize information from different sources.
Example — Smart content processor that adapts to document type:
- Prompt Call with
seclai_content_tools+seclai_memory_banks→ "Analyze the incoming document. Check memory for prior context on this topic. Produce a structured analysis and save key findings to memory."
The model inspects the document with content tools, checks memory for related entries, and writes new findings back — all driven by the content rather than a fixed script.
Pros:
- Adaptive — The model reacts to what it finds. It can search for more detail, try different queries, or skip unnecessary lookups.
- Handles open-ended tasks — Research, fact-checking, multi-source aggregation, and exploratory analysis work well because the model drives the process.
- Fewer steps to maintain — A single tool-enabled prompt call can replace a chain of explicit steps.
Cons:
- Less predictable — The model may call tools in unexpected ways or skip calls you expected it to make.
- Higher token cost — Each tool call and its results consume tokens. Multiple rounds of tool calls can be expensive.
- Requires function-calling models — Only models that support function calling can use tools. See Models.
- Harder to debug — When the model makes a poor decision about which tools to call, it can be harder to diagnose than a failed explicit step.
Choosing an Approach
| Scenario | Recommended approach |
|---|---|
| Fixed URL or query known at design time | Explicit Web Fetch or Web Search step |
| Open-ended research across multiple sources | Prompt call with seclai_web_tools and/or seclai_knowledge_base |
| Always search the same knowledge base | Explicit Search Knowledge Base step |
| Let the model choose which knowledge base to search | Prompt call with seclai_knowledge_base (model discovers KBs via list_knowledge_bases) |
| Process a specific incoming document | Explicit Load Content step or Insight step |
| Explore documents dynamically based on prompt context | Prompt call with seclai_content_tools |
| Always write to a specific memory bank and key | Explicit Add Memory step |
| Let the model decide what to remember | Prompt call with seclai_memory_banks |
You can also combine both approaches in a single agent. Use explicit steps for the deterministic parts of the pipeline (fetching a known URL, loading a specific document) and tool-enabled prompt calls for the parts that benefit from model autonomy (analysis, synthesis, follow-up research).
Tool Groups
Tools are organized into four groups. Enable one or more groups per prompt call step — or expand a group in the step editor and enable individual member tools for finer control. A step's tool list accepts either a group ID (enables every tool in the group) or individual member tool IDs (e.g. seclai_grep_content); the two forms compose. A fully-selected group is stored as its group ID, so a tool later added to that group is automatically enabled.
| Group ID | Name | Tools | Purpose |
|---|---|---|---|
seclai_web_tools | Seclai Web Tools | seclai_web_search, seclai_web_fetch | Search the web and fetch page content |
seclai_knowledge_base | Seclai Knowledge Base | search_knowledge_base, list_knowledge_bases | Semantic search across your knowledge bases |
seclai_content_tools | Seclai Content Tools | seclai_load_content, peek_content, seclai_grep_content, get_content_stats, list_content_sources | Inspect and search within indexed source documents |
seclai_memory_banks | Seclai Memory Banks | list_memory_banks, add_chat_turn, seclai_add_memory, seclai_search_memory, load_chat_history, seclai_load_memory | Read and write persistent memory across agent runs |
Cloud Drive Tools are enabled separately — not from this group list, but via the Cloud Drive Access binding on a prompt call (scoped to one connection).
Web Tools
Web tools let the model search the web and fetch page content during generation. These tools are provided by the Seclai platform and available for every model that supports function calling — you don't need a vendor that offers built-in web browsing or internet access. The model decides which URLs to fetch and which queries to run based on the prompt context, making web tools ideal for research tasks where the set of pages isn't known in advance.
When to use web tools vs. web steps:
- Web tools (
seclai_web_toolsin a prompt call) — The model autonomously decides what to search and fetch. It can issue multiple searches, follow links, and refine queries across tool-call rounds. Best for open-ended research, fact-checking, and multi-source aggregation. - Web Fetch / Web Search steps — Execute exactly one fetch or search with a fixed (or template-substituted) URL/query. Best for deterministic pipelines where you know the target URL or query ahead of time.
seclai_web_search
Search the web and return results with titles, descriptions, and content snippets.
| Parameter | Type | Required | Description |
|---|---|---|---|
query | string | Yes | The search query |
limit | integer | No | Maximum number of results to return (1–20, default 5) |
Each result includes a URL, title, description, and a content snippet from the page.
seclai_web_fetch
Fetch a web page and return its content in the specified format.
| Parameter | Type | Required | Description |
|---|---|---|---|
url | string | Yes | The URL of the web page to fetch. Must start with http:// or https://. |
format | string | No | Output format — markdown (default), rawHtml, or text. |
Returns the page URL, title, content in the requested format, and content type.
Knowledge Base Tools
Knowledge base tools let the model search your knowledge bases using semantic similarity and discover which knowledge bases are available. How the tools are configured depends on the context:
Scenarios
Scenario 1: Knowledge base ID in the prompt
When the prompt or system prompt explicitly contains a knowledge base ID (e.g. hardcoded or injected via {{metadata.knowledge_base_id}}), the model receives search_knowledge_base and is expected to call it with the provided ID.
Scenario 2a: Knowledge base ID in agent run metadata
When the agent run metadata includes a knowledge_base_id field (but the prompt doesn't explicitly mention it), the search_knowledge_base tool is included with that ID as the default value for the knowledge_base_id parameter. The model can call search_knowledge_base without specifying the ID — the default is used automatically.
Scenario 2b: No knowledge base ID available
When no knowledge base ID is available in metadata or the prompt, both list_knowledge_bases and search_knowledge_base are included. The model is expected to first call list_knowledge_bases to discover available knowledge bases, then call search_knowledge_base with a valid ID from the list.
list_knowledge_bases
List all knowledge bases available in the current account. Returns the ID, name, and description of each knowledge base. The model uses this to discover which knowledge bases it can search.
This tool takes no parameters.
search_knowledge_base
Search a knowledge base using semantic similarity.
| Parameter | Type | Required | Description |
|---|---|---|---|
knowledge_base_id | string | Depends on scenario | The unique identifier of the knowledge base to search. Required in scenarios 1 and 2b. Has a default value in scenario 2a. |
query | string | Yes | The search query string |
top_n | integer | No | Maximum number of results to return (1–200, default 10) |
Each result includes the source_connection_content_version_id, source name, content title, matched text, and similarity score — allowing the model to follow up with content tools for deeper inspection.
Content Tools
Content tools let the model inspect source documents connected to your account. Each content tool (except list_content_sources) requires a source_connection_content_version_id to identify the specific document to operate on.
Scenarios
Scenario 1: Content version ID in the prompt
When the prompt or system prompt explicitly contains a source_connection_content_version_id (e.g. hardcoded or injected via {{metadata.source_connection_content_version_id}}), the model receives the content tools and is expected to call them with the provided ID. list_content_sources is included for discovery of additional content.
Scenario 2a: Content version ID in agent run metadata
When the agent run metadata includes a source_connection_content_version_id field (e.g. from a content added or content updated trigger), the content tools that require this ID are included with it as the default value. The model can call seclai_load_content, peek_content, seclai_grep_content, or get_content_stats without specifying the ID — the default is used automatically. list_content_sources is excluded since the target content is already known.
Scenario 2b: No content version ID available
When no content version ID is available in metadata or the prompt, all content tools are included along with list_content_sources. The model is expected to first call list_content_sources to discover available content sources and their content items, then call the other content tools with a valid ID from the results.
list_content_sources
List the content sources available in the current account. Returns source connections with their recent content items, including the source_connection_content_version_id needed to inspect content with other tools.
| Parameter | Type | Required | Description |
|---|---|---|---|
limit | integer | No | Maximum number of source connections to return (1–20, default 5) |
seclai_load_content
Load the full text content of a specific source document.
| Parameter | Type | Required | Description |
|---|---|---|---|
source_connection_content_version_id | string | Yes | The unique identifier of the content version to load |
peek_content
Read a character range from a source document. Useful for reading specific sections without loading the entire document.
| Parameter | Type | Required | Description |
|---|---|---|---|
source_connection_content_version_id | string | Yes | The unique identifier of the content version |
start | integer | Yes | The starting character position (0-based) |
stop | integer | Yes | The ending character position (exclusive) |
seclai_grep_content
Search within a source document for all occurrences of a text query. Returns matching lines with surrounding context.
| Parameter | Type | Required | Description |
|---|---|---|---|
source_connection_content_version_id | string | Yes | The unique identifier of the content version |
query | string | Yes | The text to search for (case-insensitive) |
get_content_stats
Get statistics about a source document including total length, line count, word count, and content type.
| Parameter | Type | Required | Description |
|---|---|---|---|
source_connection_content_version_id | string | Yes | The unique identifier of the content version |
Memory Bank Tools
Memory bank tools let the model read and write persistent memory that survives across agent runs. This is useful for agents that need to remember user preferences, track conversation history, or accumulate knowledge over time. See Memory Banks for more on memory bank types.
Memory banks come in two types:
- Conversation — Chat-style history partitioned by key and speaker (
user/assistant). - General — Flat factual entries partitioned by key, with no speaker.
list_memory_banks
List all memory banks available in the current account. Returns the ID, name, description, type, and mode of each memory bank. The model uses this to discover which memory banks it can interact with.
This tool takes no parameters.
add_chat_turn
Record a turn in a conversation memory bank. Use seclai_add_memory for general banks.
| Parameter | Type | Required | Description |
|---|---|---|---|
memory_bank_id | string | Yes | The unique identifier of the conversation memory bank |
key | string | Yes | The partition key (typically the conversation/user ID) |
content | string | Yes | The turn's text content |
speaker | string | Yes | The speaker — user or assistant |
seclai_add_memory
Write a fact to a general memory bank, partitioned by key. Use add_chat_turn for conversation banks.
| Parameter | Type | Required | Description |
|---|---|---|---|
memory_bank_id | string | Yes | The unique identifier of the general memory bank |
key | string | Yes | The partition key (e.g. user ID, topic, category) |
content | string | Yes | The text content to store |
seclai_search_memory
Search a memory bank using semantic similarity, scoped to a specific key. Works on both conversation and general banks.
| Parameter | Type | Required | Description |
|---|---|---|---|
memory_bank_id | string | Yes | The unique identifier of the memory bank |
query | string | Yes | The search query |
key | string | Yes | The partition key to search within |
top_n | integer | No | Maximum number of results to return (1–50, default 10) |
load_chat_history
Load chat turns from a conversation memory bank in chronological order. Use seclai_load_memory for general banks.
| Parameter | Type | Required | Description |
|---|---|---|---|
memory_bank_id | string | Yes | The unique identifier of the conversation memory bank |
key | string | Yes | The partition key (typically the conversation/user ID) |
order | string | No | Sort order — newest_first (default) or oldest_first |
limit | integer | No | Maximum number of entries to return (1–200, default 50) |
seclai_load_memory
Load entries from a general memory bank in chronological order. Use load_chat_history for conversation banks.
| Parameter | Type | Required | Description |
|---|---|---|---|
memory_bank_id | string | Yes | The unique identifier of the general memory bank |
key | string | Yes | The partition key to load entries for |
order | string | No | Sort order — newest_first (default) or oldest_first |
limit | integer | No | Maximum number of entries to return (1–200, default 50) |
Cloud Drive Tools
Cloud drive tools let the model browse, search, read, inspect, and (optionally) write files on one connected cloud drive mid-reasoning — issuing multiple calls, inspecting results, and adapting. Enable them as a group in the prompt-call tool picker (the cloud_drive binding) and expand it to pick individual tools — any subset of list / search / read / grep / stats / write — just like the built-in tool groups. The read / grep / stats trio gives the model the same progressive disclosure the content tools do: size a file up with stats, locate the relevant sections with grep, then read just those windows — so it never has to load a whole large file into context. Access is scoped to the one bound connection and bounded by per-run caps. Set up connections under Integrations → Cloud Drives (see the Cloud Drives guide).
Tool vs. dedicated steps: use the tool when the model should decide which files to open (exploratory, conditional). Use the deterministic List / Read / Write Cloud Drive File steps when the path is known ahead of time.
list_drive_files
List files and folders on the connected drive.
| Parameter | Type | Required | Description |
|---|---|---|---|
folder | string | Yes | Folder path to list (e.g. /reports). Empty string lists the drive root. |
recursive | boolean | No | List nested subfolders too (default false). Pair with limit — hard-capped regardless. |
limit | integer | No | Max entries per page (1–1000). Omit for a default; the system hard-caps at 1000. |
path_pattern | string | No | Optional case-insensitive glob (e.g. **/*.pdf) to keep only matching files. |
cursor | string | No | Opaque pagination cursor. Omit for the first page; pass a prior next_cursor to continue. |
Each entry includes name, path, file_id, size, is_folder, and modified_at. The response also carries has_more and next_cursor — when has_more is true, call again with next_cursor to page through a folder larger than the cap.
search_drive_files
Search the whole drive for files by name, server-side (not limited to one listed folder). Scoped to the step's path_prefix when set.
| Parameter | Type | Required | Description |
|---|---|---|---|
query | string | Yes | Text to match against file names (e.g. q3 report). |
limit | integer | No | Max results per page (1–1000). Omit for a default. |
cursor | string | No | Opaque pagination cursor. Omit for the first page; pass a prior next_cursor to continue. |
Returns matching files (folders excluded) — each with name, path, file_id, size — plus has_more and next_cursor for paging. Search returns metadata only, so it counts against the per-run call cap but not the transfer budget.
read_drive_file
Read a text file's content from the connected drive.
| Parameter | Type | Required | Description |
|---|---|---|---|
path | string | Yes | File path to read (e.g. /reports/q3.txt). |
offset | integer | No | Character offset to start from (default 0). Use next_offset from a prior read to continue. |
Returns up to ~100 KB of UTF-8 text starting at offset, plus size, has_more, and next_offset. Progressive disclosure: when has_more is true, call again with next_offset to page through a large file. The file is fetched once and cached for the run, so paging is free — only the first read of a path counts against the transfer budget.
grep_drive_file
Search within a single file for all occurrences of a text query (case-insensitive) — the drive equivalent of seclai_grep_content. Use it to locate the relevant parts of a large file, then read_drive_file at the reported offset instead of reading the whole thing.
| Parameter | Type | Required | Description |
|---|---|---|---|
path | string | Yes | File path to search within (e.g. /reports/q3.txt). |
query | string | Yes | Literal text to find (case-insensitive). |
Returns up to 20 matches, each with offset, line_number, line, and a snippet of surrounding context, plus total_matches, returned_matches, and truncated (true when more than 20 matched). The file is fetched once and shares the read cache, so grepping a file you already read (or vice versa) costs no extra transfer budget.
drive_file_stats
Get statistics about a single file — the drive equivalent of get_content_stats. Useful for deciding how to process a file (read whole, page, or grep).
| Parameter | Type | Required | Description |
|---|---|---|---|
path | string | Yes | File path to inspect (e.g. /reports/q3.txt). |
Returns size (bytes), char_count, line_count, word_count, and content_type. Note the byte size is already available from the list/search results, so if you only need to gauge how big a file is, use those — this tool's unique value is the content counts (char/line/word), which require reading the file. It therefore downloads the file (bounded by the transfer budget) on first touch, but shares the read cache, so a later read/grep of the same file costs no extra budget.
write_drive_file
Write text content to a file, creating or overwriting it (missing parent folders are created). Only available when the write tool is enabled (i.e. write_drive_file is in enabled_tools, or the legacy allow_write is set) — otherwise the model gets list + read only.
| Parameter | Type | Required | Description |
|---|---|---|---|
path | string | Yes | Destination file path (e.g. /reports/summary.txt). |
content | string | Yes | The text content to write. |
overwrite | boolean | No | Replace an existing file (default true; false auto-renames on a clash). |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
cloud_drive_connection_id | uuid | Required | The connection the tools operate on — the model only sees files on this one drive. |
enabled_tools | string[] | null | null | Which of list_drive_files / search_drive_files / read_drive_file / grep_drive_file / drive_file_stats / write_drive_file the model may call — pick any subset (like enabling individual tools in a group). Null = derive from allow_write (list + read, plus write when set; search / grep / stats are opt-in). |
allow_write | boolean | false | Whether the model gets write_drive_file. Kept in sync with enabled_tools when that is set; use enabled_tools for finer control (e.g. read-only, or write-only). |
path_prefix | string | null | null | Optional folder the tools are confined to (e.g. /reports); list/read/write outside it are refused. Null = the whole connected drive. |
max_calls_per_run | integer (1–200) | 20 | Hard ceiling on cloud-drive tool calls in a single run. |
max_read_mb_per_run | integer (1–500) | 25 | Cumulative read+write bandwidth ceiling (MB) across all cloud-drive tool calls in a run. |
File content returned by these tools is untrusted external data — it is prompt-injection scanned as part of the run, the same as the cloud-drive steps.
MCP Server Tools
Beyond the built-in tools, a prompt call can expose tools from your
MCP clients — saved connections to external MCP servers — so
the model can call them during its reasoning. In a Prompt Call step's
Advanced options, open MCP server tools, choose a client, and enable the
tools you want to allow. Behind the scenes each enabled tool is recorded as a
mcp:<mcp_client_id>:<tool_name> ID in the step's tools list.
- Use Add all when a client exposes a handful of tools; select individually for larger servers.
- Up to 20 MCP tools can be enabled on a single prompt step, to keep the model's tool list (and context) manageable.
- The selector lists a client's cached tools — click Refresh tools (here or on the client's detail page) if the catalog is empty or out of date.
- Prefer the explicit MCP Client Call step when you always call the same tool with known arguments; use prompt-call MCP tools when the model should decide which tool(s) to call at runtime.
- Trust boundary: a tool's name, description, and parameter schema come from the external MCP server and are shown to the model. Only enable tools from MCP servers you trust — a hostile server could craft tool descriptions intended to steer the agent. Seclai bounds the size of what's injected, blocks private/internal targets, and never sends your other secrets to the server, but it cannot vet the intent of a third-party tool's description.
Usage Notes
- Tools are available for both simple format and JSON template format prompt call steps.
- Multiple tool groups can be enabled on a single prompt call step.
- The model decides when and how to call tools based on the prompt and available context.
- Multiple tool-call rounds are supported — the model can call tools, receive results, and call more tools before producing its final response.
- Tool results are included in the conversation context and count toward the model's token usage.
- All tools are platform-provided — web search, knowledge base retrieval, and memory tools work with any function-calling model, regardless of vendor.
- Not all models support function calling. Look for the tool-use badge in the Models catalog to find compatible models.
Next Steps
- Prompt Call Step — Configure prompt call steps with tools
- Agents — Create and configure agents
- Knowledge Bases — Set up knowledge bases for semantic search
- Memory Banks — Create persistent memory for agents
- Content Sources — Connect content sources to your account