Tools reference

All tools available through mcp.clawnify.com via tools/call, grouped by what they work on. Inputs marked ? are optional.

Who can call what

A client signed in as you (the clawnify mcp bridge after clawnify login, or a connector such as Claude or ChatGPT) sees every tool on this page, except that ChatGPT does not get clawnify_find_actions, clawnify_action, clawnify_execute, clawnify_write_flow, clawnify_publish_flow or clawnify_run_flow. An access token from Settings → Access tokens, wherever you paste it, sees only the tools its scopes allow:

ScopeTools
ReadListing, searching, and reading: apps, agents, integrations and their actions, Company Knowledge, Projects, memory, tasks, and usage.
Propose & write memorycompany_knowledge_propose, memory_write, memory_pin, memory_delete, project_add_document, tasks_create, tasks_update, tasks_complete.
Call your appsclawnify_app_api_read, clawnify_app_api_write, clawnify_app_api_delete.
Run codeclawnify_execute.

The rest need a signed-in person, and an access token can never call them:

  • The app tools: clawnify_get_app, and creating, updating, publishing, or deleting an app.
  • clawnify_action.
  • Writing, publishing, reviewing, archiving, or restoring Company Knowledge.
  • tasks_delete.
  • The agent tools other than clawnify_list_agents, and the flow tools.

clawnify_execute is also hidden from every client until an owner or admin turns on Settings → Access tokens → Code execution over MCP.

Choosing an organization

Every tool a signed-in client sees takes an optional org input, and clawnify_list_orgs lists the organizations the connection can act on, each with its name and handle. A connector added from a directory or plugin (Claude, ChatGPT) reaches every organization you belong to: with one, it is used automatically; with several, each call names one in org, and a call without it is refused with the list to choose from. The clawnify mcp bridge acts on the organization of the folder it starts in, when that folder has one. An access token belongs to one organization and never takes org.

clawnify_list_orgs

The organizations this connection can act on, each with its name and handle.

Input: none.

Apps

clawnify_list_apps

List the apps in your org, with each app’s id, name, status, and URL.

Input: none.

clawnify_get_app

One app’s full record: build status, URLs, and storage. Use it to check on a build after creating or updating an app.

Input: app_id.

clawnify_create_app

Build a new app from a description. Returns an app_id straight away while the build runs in the background; check on it with clawnify_get_app.

Input: name, description (what the app should do, in as much detail as you have), template?.

clawnify_update_app

Change an existing app by describing the change. Queues a rebuild; check on it with clawnify_get_app.

Input: app_id, instruction.

clawnify_publish_app

Publish an app’s current draft so everyone in your org sees it live.

Input: app_id.

clawnify_delete_app

Delete an app, its database, and its stored source. This cannot be undone.

Input: app_id.

clawnify_app_api_read, clawnify_app_api_write, clawnify_app_api_delete

Call a deployed app’s HTTP API and get its response back. Reading, writing, and deleting are separate tools, so a client such as Claude can read without asking you each time while still asking before anything changes.

Start with clawnify_app_api_read on /llms.txt for an index of the app’s endpoints, or on /api/openapi.json for the full schemas. List endpoints are paged, so pass the app’s own paging and search parameters rather than fetching everything.

Input:

  • clawnify_app_api_read: app_id, path (with its query string, e.g. /api/todos?limit=25), and optionally field, offset, limit. Sends a GET.
  • clawnify_app_api_write: app_id, method (POST, PUT, or PATCH), path, and either body (JSON) or field + edits.
  • clawnify_app_api_delete: app_id, path (e.g. /api/todos/123). Sends a DELETE.

JSON and text responses come back as they are; binary responses are summarized by size and type.

Long text fields: read in parts, edit in place

A record can hold a long text field, such as a page’s HTML or a document’s body. Rather than read or rewrite all of it:

  • Read part of it: pass field to clawnify_app_api_read with the field’s path in the response (html, or items.3.body). A long string comes back in parts: limit characters (default 50,000) from offset, with the next_offset to continue from.
  • Change part of it: pass field and edits to clawnify_app_api_write with PUT or PATCH instead of a body. Each edit replaces one exact old_text with new_text (an empty new_text deletes). The record is read, the edits are applied, and only that field is written back, so the route must update just the fields it is sent. Each old_text must appear exactly once, edits cannot overlap, and up to 50 apply together, or none do.
clawnify_app_api_write({
  app_id: "...", method: "PUT", path: "/api/compositions/c1", field: "html",
  edits: [{ old_text: "Your Title Here", new_text: "Spring Launch" }]
})

The answer is the app’s response without the edited text, plus how many edits applied and the field’s length before and after. saved_verified is true when the app’s answer shows the edited text, false when it shows something else (the route may not update that field), and null when the answer leaves the field out, so read it back to confirm.

call_app_api, the single tool these replaced, still answers calls that name it, so existing automations keep working. New work should use the three above.

Some older apps also appear as their own tools, named <app_slug>_<procedure>, which you can call directly.

Search your org’s apps by what they do, e.g. “overdue invoices”. Returns the best matches with a short snippet.

Input: query, app_slug? (search one app), limit? (default 10).

Integrations

clawnify_list_integrations

List the services your org has connected, so you know what you can reach.

Input: none.

clawnify_find_actions

Search the catalogue of integration actions by intent (“send an email”, “append a row to a sheet”), with the inputs each action expects. Use it before clawnify_action instead of guessing.

Input: query, toolkit? (one service, e.g. gmail), limit?.

clawnify_action

Run an integration action on your org’s behalf, such as sending an email or appending a row. It acts on the connected service for real.

Input: slug (from clawnify_find_actions, e.g. GMAIL_SEND_EMAIL), args? (shaped as clawnify_find_actions describes).

Not available in ChatGPT, together with clawnify_find_actions. There, ask your Clawnify agent to run the action.

Company Knowledge

Search your org’s Company Knowledge, your single source of truth for policies, pricing, brand, SOPs, and FAQs, and get back the most relevant passages with a citation. Use it whenever you need a company fact, then cite the answer as Per <Title> v<N>.

Input:

FieldTypeRequiredDescription
querystringyesWhat you need, in plain language (e.g. “refund window for annual plans”).
topKnumbernoHow many passages to return. Default 10.
doc_typestringnoOptionally narrow to one document category.

Returns the matching passages with their title, version, and citation. An empty result means nothing matched, so answer from another source.

company_knowledge_get

Read a full Company Knowledge document by id (from a search result). Returns the complete document, including links to related ones. Only published documents are visible.

Input: id (the document to read), version? (a specific version; otherwise the latest).

company_knowledge_list

Browse documents by category, folder, tags, or freshness, without a search query. Returns titles and details, not the full text.

Input: all optional, e.g. doc_type?, folder?, tags?, limit?.

company_knowledge_propose

Propose a new document, or a revision of an existing one, as a draft for a person to review. Nothing is published automatically.

Input: title and content (Markdown). To revise an existing document instead of adding a new one, also pass supersedes with its id.

company_knowledge_write

Create or edit a document directly. An edit to a published document is saved as a pending revision until someone publishes it.

Input: id? (omit to create), title, content, publish? (owners and admins: save and publish in one step).

company_knowledge_publish

Publish a draft or pending revision. It becomes citable by every agent and connected client in your org within seconds. Owners and admins only.

Input: id.

company_knowledge_review

Record whether a published document still holds: verified (optionally until a date), outdated, or ask its owner to check. Agents stop seeing an outdated document in search until it is fixed. Owners and admins only.

Input: id, state (verified, outdated, verification_requested, or none), until?, note?.

company_knowledge_archive and company_knowledge_restore

Archive a document so it drops out of search but keeps its history, or bring an archived one back. Owners and admins only.

Input: id.

Projects

projects_list

List the Projects available to the agent: its own workspace, the company file library, and any shared client or engagement Projects. Projects hold scoped working reference for one client or engagement, separate from org-wide Company Knowledge.

Input: none. Returns each Project’s id, name, and kind.

Search within one Project (get its id from projects_list) for reference about that specific client or engagement.

Input:

FieldTypeRequiredDescription
project_idstringyesThe Project to search (from projects_list).
querystringyesWhat you’re looking for, in plain language.
topKnumbernoHow many passages to return. Default 10.

project_list_documents

List the documents and files in one Project.

Input: project_id.

project_add_document

Add a Markdown document to a Project, such as notes or a client brief. It is working reference for that Project, not official Company Knowledge.

Input: project_id, content, title?.

Memory

memory_recall

Search the agent’s long-term memory and return the most relevant durable memories: preferences, past commitments, and facts it saved earlier.

Input:

FieldTypeRequiredDescription
querystringyesWhat you’re trying to remember, in plain language.
topKnumbernoHow many memories to return. Default 10.

memory_write

Save something the agent should remember across sessions: a preference, a commitment, or a stable fact. Not for throwaway task state.

Input:

FieldTypeRequiredDescription
typestringyesThe kind of memory, e.g. fact, preference, or commitment.
descriptionstringyesA one-line summary, used to rank the memory in recall.
contentstringyesThe memory itself, written as complete sentences so it makes sense on its own later.

memory_list and memory_get

Browse memories without a search query, or read one in full.

Input: memory_list takes optional filters such as type?, pinned?, and limit?; memory_get takes an id.

memory_pinned and memory_pin

Pinned memories are loaded into every new agent session. memory_pinned returns them; memory_pin pins or unpins one. Keep the pinned set small.

Input: memory_pin takes id and pinned (true or false).

memory_delete

Permanently delete a memory.

Input: id.

Tasks

The org’s Tasks board. A task goes to a person or to an agent, and an agent starts work on its task as soon as it is assigned.

tasks_list

The open tasks (and completed ones with include_completed), plus the people and agents a task can be assigned to.

Input: all optional: assignee_user_id?, assignee_server_id?, include_completed?.

tasks_create

Create a task, optionally assigned to a person (assignee_user_id) or an agent (assignee_server_id).

Input: title, due_date? (YYYY-MM-DD), and at most one assignee.

tasks_update

Change a task’s title, due date, or assignee.

Input: task_id, plus the fields to change.

tasks_complete

Mark a task done, or reopen it with completed: false.

Input: task_id, completed?.

tasks_delete

Delete a task. This cannot be undone; to close finished work, complete it instead.

Input: task_id.

Agents

These inspect and fix your org’s agents from an MCP client. Apart from clawnify_list_agents, each takes an optional agent_id from it; leave that out when your org has one agent.

clawnify_list_agents

List your org’s agents. Each entry is one agent (the “employee”) with its agent_id and status, the sub-agents it delegates to, its flows, and the integrations it can use. Start here to find which agents exist.

Input: none.

clawnify_list_agent_sessions

An agent’s stored sessions, including its sub-agents’, newest first, with token counts. A session with a very high count has grown bloated, which makes the agent slower, costlier, and more likely to drift.

Input: agent_id?, sub_agent_id?, limit?, active_minutes?.

clawnify_get_session_transcript

The latest turns of one session, to see where an agent veered, looped, or burned tokens.

Input: key (from clawnify_list_agent_sessions), agent_id?, limit?.

clawnify_list_agent_skills

The skills an agent can actually run, including shared ones, not just what is in its own folder.

Input: agent? (a sub-agent’s slug; defaults to the agent itself), agent_id?.

clawnify_get_agent_instructions

Read an agent’s AGENTS.md (its authored instructions) plus a content hash. Read this before editing and pass the hash to clawnify_set_agent_instructions.

Input: agent?, agent_id?.

clawnify_set_agent_instructions

Replace an agent’s AGENTS.md with new full text. The result shows the text before and after, so you can show the user the change, and writing again undoes it. Takes effect on the agent’s next session, no restart. AGENTS.md only: skills are edited with the clawnify CLI, flows with the flow tools below.

Pass the hash from clawnify_get_agent_instructions as base_hash: if the file changed since you read it, the write is rejected instead of overwritten.

Input: content (the full new text), base_hash?, agent?, agent_id?.

Flows

The ClawFlow authoring loop, for clients with no terminal. Each tool takes an optional agent_id (defaults to your org’s single agent).

A flow has two states, and mixing them up is the classic mistake: the draft is the file you edit, the published version is what runs. Which one a run or trigger executes depends on whether the flow has ever been published:

  • Has published versions → the latest one runs. Your draft edit is inert until you publish it.
  • Never published → the draft runs. Editing it changes production immediately, with no publish step.

clawnify_list_flows and clawnify_get_flow both report the published version (null = never published), so check it before editing.

The usual loop: clawnify_list_flows → clawnify_get_flow → edit the JSON → clawnify_write_flow (with base_hash) → clawnify_publish_flow.

In ChatGPT, flows are read-only: it can list and read flows and their runs, but not write, publish or run one. There, ask your Clawnify agent.

clawnify_list_flows

Every flow on the agent: name, description, trigger, declared inputs, steps, and the published version number (null = never published, so the draft is what runs).

Input: agent_id?.

clawnify_get_flow

One flow’s full draft definition, plus a content hash and published_version.

Input: name (the flow’s file name without .json, e.g. lead-router), agent_id?.

clawnify_write_flow

Create or replace a flow’s draft with a complete definition. Send the whole definition, not a patch: read it first and send it back modified.

The flow is validated before it is saved: an invalid flow is rejected with per-node errors and nothing is written. Pass the hash from clawnify_get_flow as base_hash and a concurrent edit fails instead of being overwritten.

Input: name, flow (the definition), base_hash?, agent_id?.

Returns the new hash, any warnings, and a note when the live published version still differs from your draft.

clawnify_publish_flow

Publish the draft as the next numbered version. This is what makes an edit live. The flow is validated again first; earlier versions are kept.

Input: name, agent_id?.

clawnify_run_flow

Start a run of the flow’s published version. Returns immediately with an instanceId, because runs are asynchronous. This performs the flow’s real side effects (messages, email, writes to connected systems), so confirm before running one on someone’s behalf.

Input: name, input? (becomes the flow’s inputs), agent_id?.

clawnify_get_flow_runs

Inspect executions. Pass run_id (an instanceId) for one run in full: its status, step-by-step trace, and approvals, which is how to find where a flow failed. Omit it for a list of runs, newest first.

Input: run_id?, name? (filter by the flow’s declared name), status? (running | completed | paused | waiting | failed | cancelled), agent_id?.

Code

clawnify_execute

Run TypeScript on your agent’s managed runtime. Returns stdout, stderr, the exit code, and how long it took.

Input:

FieldTypeRequiredDescription
codestringyesTypeScript source. Top-level await supported.
timeout_msnumbernoWall-clock timeout in milliseconds. Default 30000. Range 1000–300000.

Notes:

  • Off until an owner or admin turns on Settings → Access tokens → Code execution over MCP. An access token also needs the Run code scope.
  • Runs on your org’s managed runtime, isolated per org, with resource limits so a runaway script can’t take the agent down.
  • The agent’s environment is pre-wired: its files and your connected integrations are available.

Account

clawnify_get_usage

Your org’s current plan, its status, and when the billing period ends.

Input: none.

Errors

All tools return MCP-shaped { content: [...], isError: true } on failure. JSON-RPC errors (auth, rate limit, malformed request) come back as standard JSON-RPC error responses.

Common error codes:

CodeMeaning
-32001Unauthorized: missing or invalid token, or an access token without the scope this tool needs.
-32002Tool not found.
-32004Forbidden: your token is valid but can’t reach this org, or code execution is turned off.
-32603Internal error.
429Rate limit exceeded. Wait the number of seconds in the Retry-After header.