Skip to main content
Glama
Sign In
Ferret

Ferret

by ferret-project
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

What a room scan found

room_scan_results
Read-only

Check a room scan's status and results to see pending, ready, failed, or done outcomes; omit the scan ID to list all unfinished scans.

Instructions

Checks on a room scan from scan_room (or one taken in the app): status pending (still looking — ask again in a little while), ready (what it found: name, category, how many — tell the person and ask which to keep), failed, or done (with the items it made). Without scanId, every scan still waiting to be finished. Once the person has chosen, add_from_room_scan adds them.

Input Schema

NameRequiredDescriptionDefault
scanIdNoThe scan's id, from scan_room; left out: every unfinished scan

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • addedInput schema / properties / scanId / description
      Added value: +"The scan's id, from scan_room; left out: every unfinished scan"
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly and openWorld annotations, the description explains each status's meaning, what a ready result contains, what to do with the person's choice, and what happens when scanId is omitted. This is rich behavioral context for a read-only tool.

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

Conciseness4/5

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

The definition is front-loaded and every clause serves a purpose, but the single dense paragraph with inline parentheticals and semicolons is somewhat run-on. It could be structured more cleanly without losing content.

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?

With no output schema, the description does well to enumerate statuses and describe the ready and done payloads. It does not elaborate on the failed status or return formatting, leaving a minor gap for a tool whose results are the primary output.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents scanId and its omitted behavior. The description usefully ties scanId back to scan_room or the app, but does not add syntax or constraints beyond the schema.

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 uses a specific verb and resource, 'Checks on a room scan', and immediately clarifies the possible statuses. It also distinguishes the tool from scan_room and add_from_room_scan by naming both and describing the workflow.

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 explicitly says to use this for scans from scan_room or the app, gives polling guidance for pending scans, explains that omitting scanId returns every unfinished scan, and points to add_from_room_scan once the person has chosen.

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

Deploy Server

Other Tools