Find the tools that keep erroring

An agent says a tool “doesn’t work”, and you want to know whether that is one bad afternoon or a tool that fails every time. The Activity Log already has the answer: every errored call, with a short identifier-only note saying what kind of failure it was.

This prompt reads the error rows, groups them, and sorts them into the three kinds you can act on differently. It reads and reports, and changes nothing.

Some tools on this site seem to keep failing. Read only, change nothing.

Read the Activity Log with the status set to error, newest first, 200 rows a
page, and keep paging until created_at (it is UTC) is older than [seven days
ago]. There is no date filter on this read, so that is the only way to bound
it. If it takes more than five pages, stop and tell me how far back you got.
The total the read reports covers the whole retention window, so do not quote
it as my window's count.

Group the errors by ability, busiest first. Within each ability, group by the
detail the log recorded, and give me the first and last timestamp for each
group. Rows whose ability is "(transport)" are front-door failures, and rows
starting with "oauth:" are sign-ins, so keep each in its own section. Rows
named "aafm/write-outcome" record whether a write landed, so keep those apart
too.

Sort the details into three kinds:
- a plain code, id or slug, which this plugin recorded itself;
- a code starting with "foreign:", which came from another plugin's bridged
  tool;
- a detail naming an exception class and a file and line, which means the tool
  crashed.

Then list the tools that failed more than twice, with the kind of failure, and
say which look like a one-off and which look like a standing problem. Do not
guess at causes the log does not state.

Why this is safe to run

One ability, and it is a read. It reports failures that already happened and cannot retry, repair or delete anything.

The log keeps errors in a form that is safe to hand to an agent. The detail is limited to identifiers: an error code, or for a crash, the exception class and where it was thrown, never the exception’s message. For a failed call to another plugin’s tool, only that plugin’s error code is kept, with a foreign: prefix so you can tell whose it is.

What to do with each kind

• A plain code, id or slug is the plugin’s own note, so start with what the call passed. The Activity Log tab’s Errors view shows the argument keys the agent sent.
• A foreign: code belongs to the other plugin. Check that plugin is active and up to date, then take the code to its support. On the tab, the Plugin filter has an Other plugins (Bridge) choice that narrows the log to bridged tools.
• A crash names a class and a file. That is the line to give the plugin author, together with the tool name and the time.

Then open the Activity Log tab, click Errors, and put the tool in the Tool box. The Connection column shows which app was calling, and the Duration column shows how long the tool ran before it failed, which shows whether the tool failed fast or after a long wait.

A tool that failed once is probably a one-off. One that fails across connections, day after day, deserves a look at the source plugin first. If the rows you care about are refusals instead, use triage a burst of denied calls.

Already connected? Skip the paste. From an admin connection, ask your agent for the “find the tools that keep erroring” recipe, or just ask which tools have been failing this week, and it runs the same read on your own log.