Tool search 164,478 tools · 10,067 live servers

Write back, in your own words, what you found out about an incident — so the person who gets paged reads a diagnosis instead of a timestamp: 'failed because the upstream API returned 503; same failure as the last three nights; I retried twice and stopped' instead of 'check failed at 03:04'. The note appears on the incident's page in the dashboard, attributed to its author, in the order it was written. Take incident_id from list_open_incidents. SEND A NOTE WHETHER OR NOT YOU COULD FIX THE PROBLEM. The person reading the alert cannot see what you saw. With no note, an incident is indistinguishable from one nobody has looked at yet, so an agent that writes back only its successes leaves a record worse than none: every unexplained incident then reads as 'not looked at yet' when it may equally mean 'looked at and gave up'. 'Could not reproduce; gave up after two attempts' IS a finding and is worth writing. NOTES ARE APPEND-ONLY. There is no way to edit a note and no way to delete one — not merely unexposed: no route and no query exists for either, and an edit is refused by the database itself. A correction is a new note, never an edit, because a diagnosis whose history a reader cannot trust is not evidence. This is NOT a write-once resource: a second, third or tenth note on the same incident is normal and expected, and there is no conflict for writing one. The only conflict this tool has is the cap of 50 notes per incident, and reaching it means something is looping rather than diagnosing. A CLOSED incident still accepts notes, on purpose: the run that finally succeeded is usually the one that understood why the previous one did not, so refusing the note would lose the explanation exactly when it became available. Authorship is not yours to choose — every note written through this tool is stored as author 'agent', because this is the API-key surface; there is no author argument and supplying one is not possible.

Finds images and other attachments ALREADY in this site's media library, so an agent can name one by id — most often as the featured_image on create-content or update-content, which accepts an attachment id but had no way to discover one. Searches titles, captions and descriptions AND alt text (alt is where photographs are usually described — a file called IMG_4831.jpg may carry the alt "sunrise over the river", and a title-only search would miss it). An empty query returns the most recent uploads, which is the right way to ask "what is in here?". Returns each attachment's id, title, alt, url, mime type, pixel dimensions and upload date — the url so a client that can see images may look before it chooses, the dimensions because a 300px logo is not a featured image. READ-ONLY: it uploads nothing and changes nothing. To bring in a picture the library does not have, pass an http(s) image URL as featured_image instead and the write tools import it. There is deliberately no way to upload bytes through this server.