--- name: pasteapp-essentials description: "How to use the Pasteapp connector well and safely: confirm which Pasteapp context applies, check status before relying on it, and handle the single read-only status tool, whose behaviour is known only from its name. Use when the user asks anything about Pasteapp, says \"check Pasteapp\", \"is Pasteapp working\", \"what is my Pasteapp status\", or before any task that depends on Pasteapp state." --- # Use the Pasteapp connector This connector exposes one tool, `paste_status`. Its name suggests it reads status. Nothing else about it is known to you: not its inputs, its output shape, or which account or workspace it reads from. Treat every answer it gives as a snapshot to report, not as a fact to build on without saying where it came from. ## 1. Confirm which Pasteapp context applies Before calling anything, establish what the user means by "Pasteapp": a specific account, workspace, project or environment. If they have not said, ask one short question. Do not assume the default. - If the user names a context, state it back in your reply so they can correct you. - If the user has several Pasteapp contexts in mind, run the check for one, report it, then ask whether to check the next. Do not blend results from different contexts into one answer. - If you cannot tell from the connector which context a result belongs to, say so explicitly rather than attaching a label you were not given. ## 2. Check status before relying on it When a task depends on Pasteapp being available or in a certain state, call `paste_status` first. Use its result to decide the next step: - **It returns a clear healthy or ready signal:** proceed, and note the time you checked, since the state can change. - **It returns a warning, degraded state or error:** stop before any dependent step. Report what it said, verbatim where short, and ask how the user wants to proceed. - **It returns nothing, an empty result or an ambiguous answer:** treat this as "not established", not as healthy. Say so. - **It fails to run, times out or is refused:** report the failure. Do not retry in a loop; one retry is reasonable, after which report it and stop. Do not infer status from the absence of an error. A silent result is not a passing check. ## 3. Choose the right depth for the question Use `paste_status` for questions about current state. Do not present its result as a history, trend or audit trail: a single status read cannot show those. If the user asks what changed over time, say the connector gives only a current snapshot and offer to check again later so the two readings can be compared. ## 4. Handle what the tool does not tell you Because `paste_status` is known only by name, be explicit about its limits in your reply: - Do not describe fields, metrics or counts it may return beyond what it actually returned in this conversation. - Do not guess at why a state holds. Report the state; say the cause is not established unless the output states it. - If the user asks for a detail you have not seen in the output, say you did not see it and that you can check again, rather than filling the gap. ## Common patterns and traps - **Treating a single read as current forever.** Status goes stale. Say when you checked and re-check before any consequential step. - **Mixing contexts.** A healthy result for one Pasteapp context says nothing about another. Keep each result attached to the context it came from. - **Reading silence as success.** An empty or unclear answer is unknown, not green. - **Over-explaining the tool.** The user needs the state and its age, not a tour of the connector. - **Guessing the cause.** A degraded status with no stated reason is a finding to escalate, not a diagnosis to invent. - **Retry storms.** Repeated calls to a failing tool add noise and change nothing. Stop after a reasonable attempt. ## Output ``` Context: Checked: