Tools Reference - Paradime

The following tools can be specified in the tools.list field of an agent YAML. Use allowlist mode to restrict an agent to only the tools it needs; use denylist mode to remove specific tools from the default set.

No tools block = full tool access — except for the explicit-allowlist tools below, which are never available unless named in an allowlist block.

Filesystem

Tool	Description
`read_file`	Read the contents of a file in the repo
`write_file`	Write or overwrite a file in the repo
`search_files_and_directories`	List and navigate the repo file structure
`ripgrep_search`	Fast text search across files

Web & Docs

Tool	Description
`execute_web_search`	Search the web for current information
`extract_url_content`	Fetch and read the content of a URL
`perplexity_search`	AI-powered web search via Perplexity
`search_paradime_docs`	Search the Paradime help documentation
`get_paradime_doc_page`	Fetch the full content of a specific Paradime help docs page

SQL & Terminal

Tool	Description
`run_sql_query`	Execute a SQL query against the connected warehouse
`run_terminal_command`	Run a shell command (e.g. dbt™ commands)
`get_snowflake_query_performance_stats`	Deep-dive into a specific Snowflake query by ID
`get_bigquery_query_performance_stats`	Deep-dive into a specific BigQuery job by its ID

Orchestration

Tool	Description
`invoke_agent`	Spawn a child agent defined in `agents_squad`
`notify_parent_session`	Wake a parent agent waiting on a callback
`run_subagent`	Run a lightweight sub-task without a full agent pod

Subagents run with a reduced toolset. A subagent spawned via run_subagent gets the read-oriented base tools (filesystem reads, web search, docs, warehouse metadata, Bolt inspection, connected integrations) but not write_file, run_sql_query, run_terminal_command, multi-repository tools, or orchestration tools.

Agent Skills

Tool	Description
`load_skill_instructions`	Load the full instructions of a named Agent Skill (`SKILL.md`) discovered in the repository

Skills discovered in the repository are listed in the agent’s context automatically; the agent calls load_skill_instructions to pull in the full instructions when needed. If your agent uses allowlist mode, remember to include load_skill_instructions — omitting it disables Agent Skills for that agent.

Multi-Repository

Tool	Description
`list_accessible_repos`	List all repositories accessible via the configured git provider integration
`clone_additional_repo`	Clone an additional repository into the agent workspace as a secondary repo for cross-repo changes

Slack

Tool	Description
`post_slack_message`	Post a message to a Slack channel
`find_slack_thread`	Search recent channel history for an existing message (e.g. a PagerDuty incident alert) that the session should attach to
`attach_session_to_slack_thread`	Bind the running session to an existing Slack thread — status updates and `post_slack_message` flow to that thread, and @mentions in the thread resume the session

find_slack_thread and attach_session_to_slack_thread are explicit-allowlist tools — they read channel history and rebind the session, so an agent YAML must name them in an allowlist block to use them. They are built for self-healing agents triggered via the external API that need to run inside an incident thread already posted by an alerting tool.

Integrations

Tool	Description
`get_linear_issue`	Read a single Linear issue by ID (requires Linear integration)
`list_linear_issues`	List Linear issues filtered by team, assignee, workflow state, label or priority (requires Linear integration)
`create_linear_issue`	Create a new Linear issue (requires Linear integration)
`update_linear_issue`	Update fields or workflow state of an existing Linear issue (requires Linear integration)
`add_linear_comment`	Add a comment to an existing Linear issue (requires Linear integration)
`get_jira_issue`	Fetch details of a Jira issue by key or URL (requires Jira integration)
`list_jira_issues`	List Jira issues filtered by project, assignee, status, label — or a raw JQL query (requires Jira integration)
`create_jira_issue`	Create a new Jira issue in a project with summary, description, issue type, priority, and labels (requires Jira integration)
`update_jira_issue`	Update fields (summary, description, priority, assignee, labels) or transition the status of an existing Jira issue (requires Jira integration)
`add_jira_comment`	Add a comment to an existing Jira issue (requires Jira integration)
`get_confluence_page`	Read a Confluence page (requires Confluence integration)
`create_confluence_page`	Create a new Confluence page (requires Confluence integration)
`update_confluence_page`	Update an existing Confluence page (requires Confluence integration)
`create_confluence_footer_comment`	Add a footer comment to a Confluence page (requires Confluence integration)
`create_confluence_inline_comment`	Add an inline comment to a Confluence page (requires Confluence integration)
`search_google_drive_files`	Search files in Google Drive (requires Google Drive integration)
`read_google_doc`	Read the content of a Google Doc (requires Google Docs integration)
`read_google_sheet`	Read data from a Google Sheet (requires Google Sheets integration)
`search_notion`	Search pages and databases in Notion (requires Notion integration)
`fetch_notion_page`	Fetch the content of a Notion page (requires Notion integration)
`get_notion_page_comments`	Read the comments on a Notion page (requires Notion integration)

Integration tools require a connected integration. Linear, Jira (Jira Cloud or Jira Data Center), Confluence, Google Drive / Docs / Sheets, and Notion tools only become available when the workspace has the corresponding connection. Issues created by an agent are automatically tagged with a dinoai label and include a “Created by DinoAI” attribution line in the description.

Bolt The background agent can both inspect and trigger / retry Bolt schedules and runs. Triggered runs go through Paradime’s normal scheduler — custom commands are validated server-side before dispatch, so an agent cannot run arbitrary shell.

Tool	Description
`list_bolt_schedules`	List active Bolt schedules in the workspace (name, UUID, cron, owner, commands). Use first to discover valid `schedule_name_str` values.
`get_bolt_run_logs`	Fetch AI-generated summaries of failed commands from a Bolt run. Pass `run_id` to inspect a specific run, or `schedule_name_str` to get the latest finished run of a named schedule.
`trigger_bolt_schedule_run`	Trigger a Bolt schedule run by name. Optional `commands` to override the schedule’s commands (validated server-side); optional `branch` to override the git branch. Returns the new `run_id`.
`retry_bolt_run`	Retry a specific failed Bolt run by `run_id`. Creates a new run that resumes from the failed command; the original run is unchanged.
`retry_latest_bolt_schedule_run`	Retry the latest failed run of a Bolt schedule by name, without needing to know the run ID. Returns the new `run_id`.

Custom commands are gated. When an agent passes commands to trigger_bolt_schedule_run, each entry is checked against Paradime’s allow-list of safe commands (is_allowed_command). Disallowed commands return an [ERROR] and the run is not dispatched.

Typical pattern: list_bolt_schedules → trigger_bolt_schedule_run (or retry_latest_bolt_schedule_run) → get_bolt_run_logs with the returned run_id to inspect outcome.

Explicit-allowlist tools

The following tools perform real, billable side effects on the workspace (triggering or retrying Bolt runs) or grant sensitive capabilities (reading Slack channel history, rebinding a session to another Slack thread). They are never available unless the agent’s YAML explicitly names them in an allowlist block — Slack-triggered sessions, sessions without an agent YAML, and denylist-mode agents never see them:

trigger_bolt_schedule_run
retry_bolt_run
retry_latest_bolt_schedule_run
find_slack_thread
attach_session_to_slack_thread

tools:
  mode: allowlist
  list:
    - list_bolt_schedules
    - get_bolt_run_logs
    - retry_latest_bolt_schedule_run   # side-effectful: must be named explicitly
    - find_slack_thread                # sensitive: must be named explicitly
    - attach_session_to_slack_thread   # sensitive: must be named explicitly

Data Warehouse Warehouse tools are automatically available based on your workspace’s connected data warehouse. Each warehouse adds its own schema-navigation tools (list databases → schemas → tables → columns), e.g. list_all_snowflake_databases, list_all_schemas_in_snowflake_database, list_all_tables_in_snowflake_schema, list_all_columns_in_snowflake_table. Supported warehouses:

Snowflake
BigQuery
Redshift
Databricks
Trino
SQL Server
ClickHouse
Microsoft Fabric

YAML Configuration — How to use tools.mode and tools.list
Agent-to-Agent Delegation — Using invoke_agent and notify_parent_session
Examples — See tutorials on how to get started deploying agents

​Explicit-allowlist tools

​Related

Explicit-allowlist tools

Related