---
title: Fix and improve your app
description: 'Once your app is live, ask your agent to check it for problems, read what people said, and ship the fix, all in one pass.'
sidebar:
  label: Fix and improve your app
  order: 4
---

## Check for problems

Ask your agent to open the app. Every `get_app` call attaches a summary of what broke since the current revision was published: runtime errors, CSP violations (the browser blocking something the app tried to load), mismatches between the app's interface and its backend, failed API calls, and app load errors, each with a count and a recent example. If nothing broke, the summary doesn't show up at all.

That summary only covers the current revision. The full log goes back across every revision.

## Read what people said

People using the app can send a bug report or a suggestion from a button Charming puts in the app's toolbar, no code required on your end. Ask your agent to check an app's feedback and it lists what people said, newest first. See [Feedback](../capabilities/feedback) for how the button works and what a submission looks like.

## Ship the fix

Once your agent knows what's broken, from the runtime summary, the feedback, or both, ask it to fix the app. It calls `update_app` with either full replacement source or a small set of exact-string edits; the call is synchronous, so the fixed version is live the moment it returns. Whatever the app has stored survives the update: only the code changes, not the data. See [Data storage](../capabilities/data-storage) for what "survives" covers and [How Charming works](../concepts/how-charming-works) for the full build-and-update cycle.

## Technical

An agent runs this whole loop with three calls: `get_app` for the runtime summary, `list_feedback` for what people said, and `update_app` to ship the fix. None of them needs the app's activity log to run the loop day to day; that log is there for when the summary isn't enough.

### Copy this prompt for your agent

```text
Check my Charming app for problems and fix what you find. Read
https://charm.ing/docs/guides/fix-and-improve-your-app.md first. Open
the app, review any runtime issues and feedback attached to it, and
ship a fix for anything actionable. Ask me before making a change
that isn't obvious from the issues or feedback text.
```

### How an agent performs this job

[`get_app`](/docs/technical-reference/mcp/tools/get_app) returns current-revision issues when present and links the full activity log.

[`list_feedback`](/docs/technical-reference/mcp/tools/list_feedback) reads user and agent feedback. See [Feedback](../capabilities/feedback) for the workflow.

[`update_app`](/docs/technical-reference/mcp/tools/update_app) accepts full source or exact edits. Update the description when app behavior changes.

### The contract

The generated [MCP reference](/docs/technical-reference/mcp) and [REST API reference](/docs/reference) define schemas, filters, and auth errors.

## Related

- [Feedback](../capabilities/feedback)
- [Data storage](../capabilities/data-storage)
- [How Charming works](../concepts/how-charming-works)
- [Docs home](..)

Found a bug or need a feature? [Tell us](/docs/capabilities/feedback) with `submit_feedback` or `POST /app/{id}/feedback`. Your feedback shapes what we build next.