Skip to main content
Glama

list_recycle_bin

Read-onlyIdempotent

List soft-deleted items in the org recycle bin. Non-privileged callers only see items they themselves deleted; managers/admins see every item. Filter by entityType (project|task|proposal|document) and/or a substring on the title. Newest deletions first.

Input Schema

NameRequiredDescriptionDefault
limitNoCap on rows. Default 50, max 200.
searchNoOptional case-insensitive substring match on title.
entityTypeNoFilter to one entity type. Omit (or pass "all") for every type.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing the permission-based visibility rule (non-privileged callers see only their own deletions) and the sort order (newest deletions first), which are meaningful behavioral traits an agent can't infer from annotations.

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?

Three sentences, each earning its place: scope, visibility rule, filters, ordering. Front-loads the resource and outcome; no repetition or filler.

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

Completeness4/5

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

For a read-only list tool with no output schema, the description covers scope, permissions, filters, and ordering adequately. It could mention pagination behavior or the default/max limit handling, but the limit cap is already in the schema, so remaining gaps are minor.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds value the schema lacks: it supplies the concrete entityType values (project|task|proposal|document) and the 'all' sentinel, and clarifies the two filters are combinable ('and/or') and that search matches on title.

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?

States a specific verb and resource ('List soft-deleted items in the org recycle bin'), which is unambiguous and distinguishes it from every sibling list_* tool (list_documents, list_projects, etc.) since none other targets the recycle bin.

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

Usage Guidelines4/5

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

Explains result scoping by caller privilege (self-deleted only vs. everything for managers/admins) and enumerates the available filter dimensions, giving clear context for when to reach for this tool. It does not name an alternative or state exclusions, but no sibling competes for this function.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.