> ## Documentation Index
> Fetch the complete documentation index at: https://help.heydenada.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What agents can do

> Every tool Denada's MCP server exposes, organized by area, and how the checkout and commit model works

Once [connected](/agents/connecting), an agent sees a set of tools covering projects, libraries, images, fonts, docs, and more. Tools respect the same permissions as the user whose token is used — an agent can only see and change what you can.

<Note>
  Some tool names say `template` — that's the historical name for projects in Denada's data model. The tools operate on your projects; the surrounding documentation the agent reads makes this clear.
</Note>

## Projects

| Tool                      | What it does                                                           |
| ------------------------- | ---------------------------------------------------------------------- |
| `list_templates`          | Lists the team's projects with names, subjects, and ids                |
| `create_template`         | Creates a new, empty project bound to a library                        |
| `checkout_template`       | Downloads a project as editable files (blocks, parameters, variations) |
| `commit_template`         | Commits edited files back as one all-or-nothing change                 |
| `update_template_library` | Refreshes a project to the latest version of its library               |
| `render_template`         | Returns a URL rendering the project to final HTML for inspection       |
| `delete_template`         | Deletes a project (locked projects can't be deleted)                   |

## Libraries

| Tool                     | What it does                                                            |
| ------------------------ | ----------------------------------------------------------------------- |
| `list_libraries`         | Lists the team's libraries with their ids, names, and types             |
| `get_library_overview`   | Returns a library's structure: blocks, parameters, and instructions     |
| `checkout_library`       | Downloads a whole library as editable files (shell, blocks, parameters) |
| `commit_library`         | Commits edited files back as a new version, with a message              |
| `new_library`            | Creates a new, empty library                                            |
| `render_library_preview` | Returns a URL rendering the library (or one block) with example values  |

## Images

| Tool               | What it does                                                           |
| ------------------ | ---------------------------------------------------------------------- |
| `list_collections` | Lists the team's image collections and their usage instructions        |
| `search_assets`    | Searches the image library by text (semantic or keyword)               |
| `get_asset`        | Inspects one image: hosted URL, metadata, and a visible preview        |
| `create_asset`     | Saves an image to the team's image library                             |
| `generate_image`   | Generates an image from a prompt, optionally remixing reference images |
| `upload_image`     | Hosts an image file from the agent's workspace                         |

<Note>
  `generate_image` only works when your team's [AI images setting](/image-library/ai-images) is enabled. Teams that keep it off can still search and place existing assets.
</Note>

## Fonts

| Tool          | What it does                                                     |
| ------------- | ---------------------------------------------------------------- |
| `list_fonts`  | Lists the team's hosted fonts with CDN URLs for use in libraries |
| `create_font` | Hosts a font file (WOFF2, WOFF, TTF, OTF) on the team's CDN      |

Hosted fonts are the same ones shown in the team's [Fonts](/libraries/fonts) area.

## Docs

| Tool         | What it does                                           |
| ------------ | ------------------------------------------------------ |
| `list_docs`  | Lists the team's docs and folders (the knowledge base) |
| `get_doc`    | Reads a doc's content                                  |
| `create_doc` | Creates a new doc from text content                    |
| `edit_doc`   | Edits a doc by exact find and replace                  |
| `update_doc` | Replaces a doc's content, renames it, or moves it      |
| `delete_doc` | Deletes a doc                                          |

## Checking its work

| Tool                  | What it does                                                          |
| --------------------- | --------------------------------------------------------------------- |
| `screenshot_page`     | Renders a URL in a headless browser and returns a screenshot          |
| `fetch_rendered_page` | Loads a URL in a headless browser and returns the content as markdown |

Agents typically pair these with `render_template` or `render_library_preview` to visually verify edits before declaring them done.

## Everything else

| Tool            | What it does                                                                   |
| --------------- | ------------------------------------------------------------------------------ |
| `get_teams`     | Lists the teams you belong to, with membership level and plan                  |
| `send_feedback` | Sends a bug report, feature request, or question to the Denada team            |
| `read_guide`    | Reads the built-in guides on libraries, projects, images, email HTML, and more |

## The checkout and commit model

Editing projects and libraries works like lightweight version control:

1. **Checkout.** `checkout_template` or `checkout_library` returns a short-lived download URL for a gzipped tarball containing the content as ordinary files — JSON for structure and parameters, HTML for blocks and the shell — plus a `baseHash` identifying the version checked out.
2. **Edit.** The agent extracts the files in its workspace and edits them with its normal tools, changing only what needs to change.
3. **Commit.** `commit_template` or `commit_library` uploads the whole directory back with the `baseHash` and a short message. The commit is all-or-nothing:
   * **Success** — the change is applied atomically and appears in the version history with the agent's message.
   * **Validation failure** — nothing is applied; the agent gets a list of errors to fix before retrying.
   * **Conflict** — if the content changed since the checkout (say, a teammate edited it in the app), the commit is rejected. The agent checks out fresh, reapplies its changes, and retries — so nobody's work gets silently overwritten.

Because every commit lands in the same version history as in-app edits, you can review and roll back agent changes just like any other — see [version history](/editor/version-history).