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:
| Scope | Tools |
|---|---|
| Read | Listing, searching, and reading: apps, agents, integrations and their actions, Company Knowledge, Projects, memory, tasks, and usage. |
| Propose & write memory | company_knowledge_propose, memory_write, memory_pin, memory_delete, project_add_document, tasks_create, tasks_update, tasks_complete. |
| Call your apps | clawnify_app_api_read, clawnify_app_api_write, clawnify_app_api_delete. |
| Run code | clawnify_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 optionallyfield,offset,limit. Sends aGET.clawnify_app_api_write:app_id,method(POST,PUT, orPATCH),path, and eitherbody(JSON) orfield+edits.clawnify_app_api_delete:app_id,path(e.g./api/todos/123). Sends aDELETE.
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
fieldtoclawnify_app_api_readwith the field’s path in the response (html, oritems.3.body). A long string comes back in parts:limitcharacters (default 50,000) fromoffset, with thenext_offsetto continue from. - Change part of it: pass
fieldandeditstoclawnify_app_api_writewithPUTorPATCHinstead of abody. Each edit replaces one exactold_textwithnew_text(an emptynew_textdeletes). 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. Eachold_textmust 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.
clawnify_docs_search
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
company_knowledge_search
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:
| Field | Type | Required | Description |
|---|---|---|---|
query | string | yes | What you need, in plain language (e.g. “refund window for annual plans”). |
topK | number | no | How many passages to return. Default 10. |
doc_type | string | no | Optionally 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.
project_search
Search within one Project (get its id from projects_list) for reference about that specific client or engagement.
Input:
| Field | Type | Required | Description |
|---|---|---|---|
project_id | string | yes | The Project to search (from projects_list). |
query | string | yes | What you’re looking for, in plain language. |
topK | number | no | How 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:
| Field | Type | Required | Description |
|---|---|---|---|
query | string | yes | What you’re trying to remember, in plain language. |
topK | number | no | How 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:
| Field | Type | Required | Description |
|---|---|---|---|
type | string | yes | The kind of memory, e.g. fact, preference, or commitment. |
description | string | yes | A one-line summary, used to rank the memory in recall. |
content | string | yes | The 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:
| Field | Type | Required | Description |
|---|---|---|---|
code | string | yes | TypeScript source. Top-level await supported. |
timeout_ms | number | no | Wall-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:
| Code | Meaning |
|---|---|
-32001 | Unauthorized: missing or invalid token, or an access token without the scope this tool needs. |
-32002 | Tool not found. |
-32004 | Forbidden: your token is valid but can’t reach this org, or code execution is turned off. |
-32603 | Internal error. |
429 | Rate limit exceeded. Wait the number of seconds in the Retry-After header. |