Skip to main content
Glama

trash_list

Lists deleted browser profiles in the recycle bin to show which identities are still recoverable, helping you find names to restore instead of guessing.

Instructions

List the identities in the recycle bin — what is still recoverable.

Read-only. This is how you find out what can be restored: deleted identities do not appear in profiles_list, so without this you could only restore a name you already knew. Pair it with profile_restore.

Each entry carries name, engine, os, created, and deleted_at. Newest deletion first. An empty list means the recycle bin is empty.

Nothing here is gone yet — everything listed still has its cookies and login state and comes back intact via profile_restore.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.5

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so well: it declares the operation read-only, explains that listed entries are still recoverable with cookies and login state intact, and specifies ordering and empty-list behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and uses short paragraphs that each add distinct value: recovery use case, relation to siblings, return fields, ordering, empty state, and intactness of restored data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a zero-parameter tool with an output schema and no annotations, the description is complete enough for correct selection and invocation. It explains why the tool exists, how it relates to sibling tools, what the output contains, and what an empty result means.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero input parameters, so there are no input semantics to clarify beyond the baseline. The description instead adds useful output orientation by naming the fields each entry carries and the newest-first ordering.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it lists identities currently in the recycle bin and clarifies that these are recoverable. It explicitly distinguishes the tool from profiles_list by noting deleted identities do not appear there, and names profile_restore as the paired action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear use case: find out what can be restored, because deleted identities are absent from profiles_list and otherwise a caller could only restore a name already known. It also directs the agent to pair this tool with profile_restore.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.