Skip to main content
Glama

Fast.io

by io.fast.mcp

find

Read-only

Unified search across a workspace or share — ONE query, results GROUPED BY TYPE into buckets (files, metadata [workspace only], comments), each independently paginated and health-reported. Call action='describe' for the full action/param reference. This is the grouped SUPERSET; for a single result type prefer the narrower tools: storage action=search (files only), metadata action=search (lexical metadata fields only). The code-mode search tool searches the API endpoint catalog, not your content.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoAlias for search (the name storage + code-mode search use).
actionYesOperation. Use 'describe' for full action reference.
searchNoSearch query string. 1-1024 chars; empty/blank rejected (platform 1605). Searched across every applicable bucket. (Alias: query.)
share_idNoAlias for profile_id when profile_type=share.
search_inNofilename | content | both (DEFAULT). filename = name only, find-style. content = the AI's summary + semantic, NOT grep. OMIT unless you mean it — sending it changes the response shape (adds a search_metadata block); omitting reproduces today's behavior byte-for-byte. Pair filename with name_match.
context_idNoAlias for profile_id.
name_matchNoauto (DEFAULT) | exact | prefix | contains | glob. exact = whole name; prefix = starts with; contains = substring — those three are LITERAL (* and ? are ordinary chars). glob = wildcards over the WHOLE name: *.pdf, report-*.xlsx. Do NOT pre-escape. Applies when search_in is filename or both; auto keeps today's relevance. Precise modes cap the pattern at 256 chars, reject an empty one.
profile_idNoWorkspace or share opaque ID (19-digit numeric ID or custom name). Pair with profile_type. Four accepted aliases besides this one (five id params total): workspace_id, share_id, context_id, instance_id — the supplied id must match profile_type (workspace_id only with profile_type=workspace, share_id only with share).
files_limitNofiles bucket page size (default 25).
instance_idNoAlias for profile_id (REST/how-to name; profile_id is canonical).
context_typeNoAlias for profile_type.
files_offsetNofiles bucket result offset (default 0).
profile_typeNoProfile to search: "workspace" or "share". (Alias: context_type.)
workspace_idNoAlias for profile_id when profile_type=workspace.
case_sensitiveNoCase-sensitive matching for exact/prefix/contains/glob. Default false (like find -iname), which folds non-ASCII too. Ignored under name_match=auto.
comments_limitNocomments bucket page size (default 25).
metadata_limitNometadata bucket page size (default 25). Workspace only — dropped from the request on a share (shares have no metadata bucket).
comments_offsetNocomments bucket result offset (default 0).
metadata_offsetNometadata bucket result offset (default 0). Workspace only — dropped from the request on a share (shares have no metadata bucket).

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial context: results grouped into buckets, independently paginated, health-reported, metadata workspace-only, and search_in semantics (AI summary, not grep). No contradiction with 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 dense sentences: main purpose, self-reference pointer, and sibling/alternative differentiation. No filler, front-loaded with the most important information, and each sentence earns its place.

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?

For a 19-param tool with no output schema, the description covers scope (workspace/share), bucket structure, pagination/health reporting, workspace-only metadata, sibling alternatives, and a pointer to action='describe' for full reference. It is complete enough for an agent to select and invoke correctly.

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 description coverage is 100%, so the schema fully documents all 19 parameters. The tool description adds no parameter-specific details beyond pointing to action='describe', which is acceptable per the baseline for high schema coverage.

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 clearly states the tool does 'Unified search across a workspace or share' with a specific verb and resource, and defines the result structure as buckets. It differentiates from siblings by naming narrower tools like `storage action=search` and `metadata action=search`.

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?

Explicit guidance is provided: 'for a single result type prefer the narrower tools', and it warns that code-mode `search` searches the API catalog, not content. Also instructs to call action='describe' for full reference, covering when and when-not to use.

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

All Fast.io toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool covers a clearly distinct domain (auth, storage, shares, comments, events, AI, etc.), and overlapping concepts like share vs. fileshare are explicitly disambiguated with deprecation notes and cross-references. An agent can reliably select the correct tool for a task without ambiguity.

Naming Consistency3/5

Tool names are all lowercase single words, but they mix nouns (user, org, workspace) with verbs (download, find, upload) and include a hyphenated 'how-to'. There is no consistent verb_noun or noun-only pattern, though the names are still readable and memorable.

Tool Count4/5

19 tools is slightly above the typical 3-15 sweet spot, but the platform's breadth (auth, file management, sharing, collaboration, AI, metadata, and help) justifies this count. Each tool represents a substantial domain area, so none feel redundant.

Completeness5/5

The toolset provides full lifecycle coverage for the platform: authentication, user/org/workspace management, file storage/upload/download/search, sharing (both quickshare and durable file shares), comments, events, metadata pipelines, AI assistance, and product help. No obvious dead ends or missing operations are apparent.

Resources