Skip to main content

List Agent Tools

List every tool available to the Talonic embedded AI agent with impact levels from read to irreversible. Build permission-aware integrations and gates.

The agent tools endpoint returns the agent's live tool registry: it is read directly from the same registry the agent loop executes from, so the list can never drift from what actually runs. Each entry carries a stable name, a human-readable description, an impact level that classifies how consequential the operation is, a capability tag naming the permission the tool requires, a can_invoke flag stating whether the calling key can run the tool directly, and the tool's input_schema, a JSON Schema describing its arguments. Use it for tool discovery: dynamically generating tool descriptions for external AI agents, auditing available capabilities, or building permission-aware integrations.

Call this endpoint at startup to populate your integration's tool registry, or periodically to detect newly added capabilities: because the response reflects the live loop, a newly shipped tool appears here the moment it is deployed, with no docs lag. The input_schema on each entry is what makes direct invocation programmable: generate argument forms or function-call definitions from it, then run the tool through [POST /v1/agent/tools/:name/invoke](agent-invoke-tool).

The totalCount field gives the total number of registered tools, and invocable_count how many of them this key can invoke. The registry lists every tool the in-product agent operates, 61 at present, while an API key runs as the least-privilege viewer role and can invoke only the read subset, currently 32; that asymmetry is exactly why can_invoke exists, so the listing is a menu of what you can order and a transparent view of the rest. Each tool's impact field follows a four-level severity scale: read, draft_mutation, live_mutation, and irreversible. Use these levels to build confirmation gates: for example, auto-approve read tools but require user confirmation for live_mutation and above. The capability field is the finer-grained permission the loop checks against the caller's role before executing (for example data.read, source.ingest, review.resolve, spec.author).

Pair this with the Workspace Context endpoint to give your external AI agent both situational awareness (context) and available actions (tools). The tool names returned here are stable identifiers that can be referenced in custom orchestration logic or permission policies.

Impact levels follow a severity scale: read (no side effects), draft_mutation (creates drafts only), live_mutation (modifies live data), and irreversible (permanent changes like deletion). Use these to implement confirmation gates in your integration.
GET/v1/agent/tools

curl

curl -s https://api.talonic.com/v1/agent/tools \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

Response fields

toolsarrayArray of tool descriptors, read live from the agent loop's registry.
tools[].namestringUnique tool identifier.
tools[].impactstringImpact level: read, draft_mutation, live_mutation, or irreversible.
tools[].capabilitystringThe permission the tool requires, checked against the caller's role before execution (e.g. data.read, data.promote, source.ingest, review.resolve, spec.author).
tools[].descriptionstringHuman-readable description of what the tool does.
tools[].can_invokebooleanWhether the calling key can run this tool via POST /v1/agent/tools/:name/invoke. True for the read subset an API key's viewer role grants.
tools[].input_schemaobjectJSON Schema for the tool's args, as passed to POST /v1/agent/tools/:name/invoke.
totalCountintegerTotal number of registered tools.
invocable_countintegerHow many of the listed tools this key can invoke.

Response

{
  "tools": [
    {
      "name": "query_data",
      "impact": "read",
      "capability": "data.read",
      "description": "Runs a read-only SQL query over the structured cell plane.",
      "can_invoke": true,
      "input_schema": { "type": "object", "properties": { "sql": { "type": "string" } } }
    },
    {
      "name": "promote_field",
      "impact": "draft_mutation",
      "capability": "data.promote",
      "description": "Makes an already-captured field queryable. No LLM call, reversible.",
      "can_invoke": false,
      "input_schema": { "type": "object", "properties": { "field_id": { "type": "string" } } }
    }
  ],
  "totalCount": 61,
  "invocable_count": 32
}

Errors

Error responses

401unauthorizedMissing or invalid API key.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

Frequently asked questions

Can I invoke agent tools directly via the API?+
Yes, the ones whose can_invoke is true for your key: POST /v1/agent/tools/:name/invoke runs a single named tool with the arguments you supply, no model in the loop, at no credit cost. Tools whose can_invoke is false require capabilities an API key's viewer role does not grant; those run only inside in-product agent turns.
Is this list ever out of date?+
No. The response is read from the live tool registry the agent loop executes from, so it always matches what actually runs. A newly deployed tool appears immediately.
What impact levels are available?+
Four levels: `read` (safe, no side effects), `draft_mutation` (creates drafts), `live_mutation` (modifies live data), and `irreversible` (permanent changes). Use these to build confirmation gates.
How do I use impact levels to gate tool execution?+
Treat the four levels as an escalating approval ladder: auto-approve `read` tools, and require explicit user confirmation for `live_mutation` and `irreversible` tools. Tool names are stable identifiers, so you can reference them in permission policies.
Why does the list show tools I cannot invoke?+
The registry is the full surface the in-product agent operates. Listing all of it, with can_invoke marking your reachable subset, lets an integration see precisely what exists, what it can run, and why the rest is out of reach (the capability tag names the missing permission).