Fast Io

Fast.io MCP Server -- AI Agent Guide

Version: 1.104 Last Updated: 2026-02-26

The definitive guide for AI agents using the Fast.io MCP server. Covers why and how to use the platform: product capabilities, the free agent plan, authentication, core concepts (workspaces, shares, intelligence, previews, comments, URL import, metadata, workflow, ownership transfer), 12 end-to-end workflows, interactive MCP App widgets, and all 19 consolidated tools with action-based routing.

Versioned guide. This guide is versioned and updated with each server release. The version number at the top of this document tracks tool parameters, ID formats, and API behavior changes. If you encounter unexpected errors, the guide version may have changed since you last read it.

Platform reference. For a comprehensive overview of Fast.io's capabilities, the agent plan, key workflows, and upgrade paths, see references/REFERENCE.md.

1. Overview

Workspaces for Agentic Teams. Collaborate, share, and query with AI -- all through one API, free.

Fast.io provides workspaces for agentic teams -- where agents collaborate with other agents and with humans. Upload outputs, create branded data rooms, ask questions about documents using built-in AI, and hand everything off to a human when the job is done. No infrastructure to manage, no subscriptions to set up, no credit card required.

The Problem Fast.io Solves

Agentic teams -- groups of agents working together and with humans -- need a shared place to work. Today, agents cobble together S3 buckets, presigned URLs, email attachments, and custom download pages. Every agent reinvents collaboration, and there is no shared workspace where agents and humans can see the same files, track activity, and hand off work.

When agents need to understand documents -- not just store them -- they have to download files, parse dozens of formats, build search indexes, and manage their own RAG pipeline. That is a lot of infrastructure for what should be a simple question: "What does this document say?"

MCP Server

This MCP server exposes 19 consolidated tools that cover the full Fast.io REST API surface. Every authenticated API endpoint has a corresponding tool action, and the server handles session management automatically.

Once a user authenticates, the auth token is stored in the server session and automatically attached to all subsequent API calls. There is no need to pass tokens between tool invocations.

Server Endpoints

• Production: mcp.fast.io
• Development: mcp.fastdev1.com

Two transports are available on each:

• Streamable HTTP at /mcp -- the preferred transport for new integrations.
• SSE at /sse -- a legacy transport maintained for backward compatibility.

MCP Resources

The server exposes static MCP resources, widget resources, and file download resource templates. Clients can read them via resources/list and resources/read:

File download resource templates -- read file content directly through MCP without needing external HTTP access:

Files up to 50 MB are returned inline as base64-encoded blob content. Larger files return a text fallback with a URL to the HTTP pass-through endpoint (see below). The download tool responses include a resource_uri field with the appropriate URI for each file.

Dynamic resource listing: When authenticated, workspace and share file resources are dynamically listed via resources/list. MCP clients (such as Claude Desktop's @ mention picker) can discover available files without any tool calls. Up to 10 workspaces and 10 shares are enumerated, with up to 25 most recently updated root-level files from each. Resources appear as "WorkspaceName / filename.ext" or "ShareTitle / filename.ext". Results are cached for 1 minute per session. Only root-level files are listed -- subdirectories are not recursively enumerated. Use the storage tool with action list to browse deeper. The quickshare template remains template-only and is not dynamically enumerable.

MCP Prompts

The server registers MCP prompts that appear in the client's "Add From" / "+" menu as user-clickable app launchers. These are primarily for desktop MCP clients (e.g., Claude Desktop); code-mode clients (Claude Code, Cursor) do not surface prompts.

HTTP File Pass-Through

For files larger than 50 MB or when raw binary streaming is needed, the server provides an HTTP pass-through endpoint that streams file content directly from the API:

The response includes proper Content-Type, Content-Length, and Content-Disposition headers from the upstream API. Errors are returned as HTML pages. The Mcp-Session-Id header is the same session identifier used for MCP protocol communication.

Workflow Overview

The server includes workflow features for project tracking: tasks (structured work items with priorities and assignees), worklogs (append-only activity logs), approvals (formal sign-off requests), and todos (simple checklists). Enable workflow on a workspace with workspace action enable-workflow before using these tools. See the Full Agent Workflow recipe in section 6 for the complete pattern.

Best practice (IMPORTANT): After state-changing actions (uploading files, creating shares, changing task status, member changes, file moves/deletes), append a worklog entry describing what you did and why. Without worklog entries, agent work is invisible to humans reviewing the workspace. For multiple related actions (e.g., uploading several files), you may log once after the batch completes rather than after each individual action. Worklog entries are append-only and permanent.

Additional References

• Agent guide (this file): /skill.md on the MCP server -- tool documentation, workflows, and constraints.
• REST API reference: https://api.fast.io/llms.txt -- endpoint documentation for the underlying Fast.io API.
• Platform guide: references/REFERENCE.md -- capabilities, agent plan details, key workflows, and upgrade paths.

2. Authentication (Critical First Step)

Authentication is required before calling any tool except these unauthenticated tools:

• auth with actions: signin, signup, set-api-key, pkce-login, email-check, password-reset-request, password-reset
• download with action: quickshare-details

Choosing the Right Approach

There are three ways to use Fast.io as an agent, depending on whether you are operating autonomously or assisting an existing human user.

Option 1: Autonomous Agent -- Create an Agent Account

If you are operating independently (storing files, running workflows, building workspaces for users), create your own agent account with auth action signup. Agent accounts get the free agent plan (50 GB, 5,000 monthly credits) and can transfer orgs to humans when ready. This is the recommended path for autonomous agents. See Agent Account Creation below for steps.

Option 2: Assisting a Human -- Use Their API Key

If a human already has a Fast.io account and wants your help managing their files, workspaces, or shares, they can create an API key for you to use. No separate agent account is needed -- you operate as the human user. The human creates a key at Settings -> Devices & Agents -> API Keys (direct link: https://go.fast.io/settings/api-keys). Call auth with action set-api-key and the key to authenticate -- the key is validated and stored in the session automatically. API keys work as Bearer tokens and by default have the same permissions as the account owner. Keys can optionally be scoped to specific organizations, workspaces, or shares (using the same scope system as OAuth tokens), tagged with an agent_name for tracking, and given an expiration date. Unscoped keys do not expire unless revoked. Agents can also manage API keys programmatically with auth actions api-key-create, api-key-update, api-key-list, api-key-get, and api-key-delete.

Option 3: Agent Account Invited to a Human's Org

If you want your own agent identity but need to work within a human's existing organization, create an agent account with auth action signup, then have the human invite you to their org with member action add (entity_type org) or to a workspace with member action add (entity_type workspace). Alternatively the human can invite via the UI: Settings -> Your Organization -> Manage People. This gives you access to their workspaces and shares while keeping your own account separate. After accepting invitations with user action accept-all-invitations, use auth action signin to authenticate normally. Note: If the human only invites you to a workspace (not the org), the org will appear as external -- see Internal vs External Orgs in the Organizations section.

Option 4: Browser Login (PKCE)

If you prefer not to send a password through the agent, use browser-based PKCE login. Call auth action pkce-login (optionally with an email hint) to get a login URL. The user opens the URL in a browser, signs in (email/password or SSO like Google/Microsoft), and approves access. The browser displays an authorization code which the user copies back to the agent. Call auth action pkce-complete with the code to finish signing in. This is the most secure option -- no credentials pass through the agent.

PKCE login supports optional scoped access via the scope_type parameter. By default, scope_type is "user" (full account access). Other scope types restrict the token to specific entity types:

Scope inheritance: Broader scopes include access to child entities automatically:

• all_orgs includes all orgs + all workspaces + all shares within those orgs
• all_workspaces includes all workspaces + all shares within those workspaces
• org scope on a specific org includes access to all workspaces and shares within that org
• workspace scope on a specific workspace includes access to shares within that workspace
• all_shares grants direct access to all shares the user has membership in, bypassing workspace/org inheritance

The agent_name parameter controls what the user sees on the approval screen -- the screen displays "[agent_name] will act on your behalf". If omitted, only the client name is shown. Use a descriptive name so the user knows which agent is requesting access.

Approval flow by scope_type:

• user (default): Full account access. The user sees a simple approve/decline prompt with no entity picker.
• org, workspace: The user sees an entity selection screen listing their accessible entities with checkboxes, plus a read-only / read-write toggle. The user picks which entities to grant, then approves or declines.
• all_orgs, all_workspaces, all_shares: The user sees a summary of the wildcard access being requested (no entity picker), then approves or declines.

The MCP server defaults to scope_type="user" for backward compatibility.

Credit limits by account type: Agent accounts (Options 1, 3) can transfer orgs to humans when credits run out -- see Ownership Transfer in section 3. Human accounts (Option 2) cannot use the transfer/claim API; direct the human to upgrade their plan at https://go.fast.io/settings/billing or via org action billing-create.

Standard Sign-In Flow

1. Call auth with action signin, email and password.
2. The server returns a JWT auth_token and stores it in the session automatically.
3. All subsequent tool calls use this token without any manual passing.

Agent Account Creation

When creating a new account (Options 1 and 3 above), agents MUST use auth action signup which automatically registers with agent=true. Never sign up as a human account. Agent accounts provide:

• account_type set to "agent"
• Free agent plan assigned automatically
• Transfer/claim workflow enabled for handing orgs off to humans

Steps:

1. Optionally call auth action email-check with the desired email to verify it is available for registration before attempting signup.
2. Call auth action signup with first_name, last_name, email, and password. The agent=true flag is sent automatically by the MCP server.
3. The account is created and a session is established automatically -- the agent is signed in immediately.
4. Verify your email (required before using most endpoints): Call auth action email-verify with email to send a verification code, then call auth action email-verify again with email and email_token to validate the code.
5. No credit card is required. No trial period. No expiration. The account persists indefinitely.

Two-Factor Authentication Flow

1. Call auth action signin with email and password.
2. If the response includes two_factor_required: true, the returned token has limited scope.
3. Call auth action 2fa-verify with the 2FA code (TOTP, SMS, or WhatsApp).
4. The server replaces the limited-scope token with a full-scope token automatically.

Browser Login (PKCE) Flow

1. Call auth action pkce-login (optionally with email to pre-fill the sign-in form, scope_type to request scoped access, and agent_name to identify the agent).
2. The tool returns a login_url -- present it to the user to open in a browser.
3. The user signs in (email/password or SSO).
4. The user sees the approval screen showing the agent_name (or client name if not provided). Depending on scope_type: for user they simply approve; for org/workspace they select specific entities and read-only/read-write access; for all_orgs/all_workspaces/all_shares they review the wildcard access summary.
5. The user clicks Approve. The browser displays an authorization code. The user copies it.
6. Call auth action pkce-complete with the code to exchange it for an access token.
7. The session is established automatically -- all subsequent tool calls are authenticated. If scoped access was granted, scopes and agent_name are included in the response and stored in the session.

Checking Session Status

• auth action status -- checks the local Durable Object session. No API call is made. Returns authentication state, user ID, email, token expiry, scopes, and agent_name.
• auth action check -- validates the token against the Fast.io API. Returns the user ID if the token is still valid.

Session Expiry

JWT tokens last 1 hour. API keys do not expire by default, but can optionally have an expiration set via api-key-create or api-key-update with the key_expires parameter. When a JWT session expires or a time-limited API key expires, tool calls return a clear error indicating that re-authentication is needed. Call auth action signin again to establish a new session. The MCP server does not auto-refresh tokens.

Tip: For long-running sessions, use auth action status to check remaining token lifetime before starting a multi-step workflow. If the token is close to expiring, re-authenticate first to avoid mid-workflow interruptions.

Signing Out

Call auth action signout to clear the stored session from the Durable Object.

3. Core Concepts

Organizations

Organizations are top-level containers that collect workspaces. An organization can represent a company, a business unit, a team, or simply your own personal collection. Every user belongs to one or more organizations. Organizations have:

• Workspaces — the file storage containers that belong to the organization.
• Members with roles: owner, admin, member, guest, view.
• Billing and subscriptions managed through Stripe integration.
• Plan limits that govern storage, transfer, AI tokens, and member counts.

Organizations are identified by a 19-digit numeric profile ID or a domain string.

IMPORTANT: When creating orgs, agents MUST use org action create which automatically assigns billing_plan: "agent". This ensures the org gets the free agent plan (50 GB, 5,000 credits/month). Do not use any other billing plan for agent-created organizations.

Org Discovery (IMPORTANT)

To discover all available orgs, agents must call both actions:

1. org action list -- returns internal orgs where you are a direct member (member: true)
2. org action discover-external -- returns external orgs you access via workspace membership only (member: false)

An agent that only checks org action list will miss external orgs entirely and won't discover the workspaces it's been invited to. External orgs are the most common pattern when a human invites an agent to help with a specific project -- they add the agent to a workspace but not to the org itself.

Internal vs External Orgs

Internal orgs (member: true) -- orgs you created or were invited to join as a member. You have org-level access: you can see all workspaces (subject to permissions), manage settings if you're an admin, and appear in the org's member list.

External orgs (member: false) -- orgs you can access only through workspace membership. You can see the org's name and basic public info, but you cannot manage org settings, see other workspaces, or add members at the org level. Your access is limited to the specific workspaces you were explicitly invited to.

Example: A human invites your agent to their "Q4 Reports" workspace. You can upload files, run AI queries, and collaborate in that workspace. But you cannot create new workspaces in their org, view their billing, or access their other workspaces. The org shows up via org action discover-external -- not org action list. If the human later invites you to the org itself, the org moves from external to internal.

Workspaces

Workspaces are file storage containers within organizations. Each workspace has:

• Its own set of members with roles (owner, admin, member, guest).
• A storage tree of files and folders (storage nodes).
• Optional AI features for RAG-powered chat.
• Shares that can be created within the workspace.
• Archive/unarchive lifecycle management.
• 50 GB included storage on the free agent plan, with files up to 1 GB per upload.
• File versioning -- every edit creates a new version, old versions are recoverable.
• Full-text and semantic search -- find files by name or content, and documents by meaning.

Workspaces are identified by a 19-digit numeric profile ID.

Intelligence: On or Off

Workspaces have an intelligence toggle that controls whether AI features are active:

Intelligence OFF -- the workspace is pure file storage. You can still attach files directly to an AI chat conversation (up to 20 files, 200 MB total), but files are not persistently indexed. This is fine for simple storage and sharing where you do not need to query your content.

Intelligence ON -- the workspace becomes an AI-powered knowledge base. Every document and code file uploaded is automatically ingested, summarized, and indexed for RAG. This enables:

• RAG (retrieval-augmented generation) -- scope AI chat to entire folders or the full workspace and ask questions across your indexed documents and code. The AI retrieves relevant passages and answers with citations.
• Semantic search -- find files by meaning, not just keywords. "Show me contracts with indemnity clauses" works even if those exact words do not appear in the filename.
• Auto-summarization -- short and long summaries generated for every indexed document and code file, searchable and visible in the UI.
• Metadata extraction -- AI pulls key metadata from documents automatically.

Coming soon: RAG indexing support for images, video, and audio files. Currently only documents and code are indexed.

Intelligence defaults to ON for workspaces created via the API by agent accounts. If the workspace is only used for file storage and sharing, disable it to conserve credits. If you need to query your content, leave it enabled.

Agent use case: Create a workspace per project or client. Enable intelligence if you need to query the content later. Upload reports, datasets, and deliverables. Invite other agents and human stakeholders. Everything is organized, searchable, and versioned.

For full details on AI chat types, file context modes, AI state, and how intelligence affects them, see the AI Chat section below.

Shares

Shares are purpose-built spaces for exchanging files with people outside your workspace. They can exist within workspaces and have three types:

Share Features

• Password protection -- require a password for link access
• Expiration dates -- shares auto-expire after a set period
• Download controls -- enable or disable file downloads
• Access levels -- Members Only, Org Members, Registered Users, or Public (anyone with the link)
• Custom branding -- background images, gradient colors, accent colors, logos
• Post-download messaging -- show custom messages and links after download
• Up to 3 custom links per share for context or calls-to-action
• Guest chat -- let share recipients ask questions in real-time
• AI-powered auto-titling -- shares automatically generate smart titles from their contents
• Activity notifications -- get notified when files are sent or received
• Comment controls -- configure who can see and post comments (owners, guests, or both)

Two Storage Modes

When creating a share with share action create, the storage_mode parameter determines how files are stored:

• room (independent storage, default) -- The share has its own isolated storage. Files are added directly to the share and are independent of any workspace. This creates a self-contained data room -- changes to workspace files do not affect the room, and vice versa. Use for final deliverables, compliance packages, archived reports, or any scenario where you want an immutable snapshot.

• shared_folder (workspace-backed) -- The share is backed by a specific folder in a workspace. The share displays the live contents of that folder -- any files added, updated, or removed in the workspace folder are immediately reflected in the share. No file duplication, so no extra storage cost. To create a shared folder, pass storage_mode=shared_folder and folder_node_id={folder_opaque_id} when creating the share. Note: Expiration dates are not allowed on shared folder shares since the content is live.

Both modes look the same to share recipients -- a branded data room with file preview, download controls, and all share features. The difference is whether the content is a snapshot (room) or a live view (shared folder).

Shares are identified by a 19-digit numeric profile ID.

Agent use case: Generate a quarterly report, create a Send share with your client's branding, set a 30-day expiration, and share the link. The client sees a professional, branded page with instant file preview -- not a raw download link.

Storage Nodes

Files and folders are represented as storage nodes. Each node has an opaque ID (a 30-character alphanumeric string, displayed with hyphens, e.g. f3jm5-zqzfx-pxdr2-dx8z5-bvnb3-rpjfm4). The special value root refers to the root folder of a workspace or share, and trash refers to the trash folder.

Key operations on storage nodes: list, create-folder, move, copy, rename, delete (moves to trash), purge (permanently deletes), restore (recovers from trash), search, add-file (link an upload), and add-link (create a share reference).

Nodes have versions. Each file modification creates a new version. Version history can be listed and files can be restored to previous versions.

Conflict resolution (REPLACE by default): When a file operation encounters an existing file with the same name in the target folder, the default behavior is to replace (overwrite) the existing file:

• Upload (addfile) -- silently overwrites the existing file. The previous content is preserved as a version entry, recoverable via storage action version-list / version-restore.
• Move / Copy -- trashes the existing conflicting file, then completes the operation. The old file is recoverable from trash.
• Restore from trash -- trashes the existing conflicting file, then restores.
• Folder conflicts and type mismatches (file vs folder) still fall back to rename (e.g. folder (2)).

This means uploading a file with the same name as an existing file will overwrite it, not create a renamed copy like report (2).pdf. If you need multiple files with the same name to coexist, rename them before uploading.

Notes

Notes are a storage node type (alongside files and folders) that store markdown content directly on the server. They live in the same folder hierarchy as files, are versioned like any other node, and appear in storage listings with type: "note".

Creating and Updating Notes

Create notes with workspace action create-note, read with workspace action read-note, and update with workspace action update-note.

Creating: Provide workspace_id, parent_id (folder opaque ID or "root"), name (must end in .md, max 100 characters), and content (markdown text, max 100 KB).

Reading: Provide workspace_id and node_id. Returns the note's markdown content and metadata.

Updating: Provide workspace_id, node_id, and at least one of name (must end in .md) or content (max 100 KB).

Notes as Long-Term Knowledge Grounding

In an intelligent workspace, notes are automatically ingested and indexed just like uploaded documents. This makes notes a way to bank knowledge over time -- any facts, context, or decisions stored in notes become grounding material for future AI queries.

When an AI chat uses folder scope (or defaults to the entire workspace), notes within that scope are searched alongside files. The AI retrieves relevant passages from notes and cites them in answers.

Key behaviors:

• Notes are ingested for RAG when workspace intelligence is enabled
• Notes within a folder scope are included in scoped queries
• Notes with ai_state: ready are searchable via RAG
• Notes can also be attached directly to a chat via files_attach (check ai.attach is true in storage details)

Use cases:

• Store project context, decisions, and rationale. Months later, ask "Why did we choose vendor X?" and the AI retrieves the note.
• Save research findings in a note. Future AI chats automatically use those findings as grounding.
• Create reference documents (style guides, naming conventions) that inform all future AI queries in the workspace.

Other Note Operations

Notes support the same storage operations as files and folders: move (via storage action move), copy (storage action copy), delete/trash (storage action delete), restore (storage action restore), version history (storage action version-list), and details (storage action details).

Linking Users to Notes

• Note in workspace context (opens workspace with note panel): https://{domain}.fast.io/workspace/{folder_name}/storage/root?note={note_id}
• Note preview (standalone view): https://{domain}.fast.io/workspace/{folder_name}/preview/{note_id}

AI Chat

AI chat lets agents ask questions about files stored in workspaces and shares. Two chat types are available, each with different file context options.

AI chat is read-only. It can read, analyze, search, and answer questions about file contents, but it cannot modify files, change workspace settings, manage members, or access events. Any action beyond reading file content — uploading, deleting, moving files, changing settings, managing shares, reading events — must be done through the MCP tools directly. Do not attempt to use AI chat as a general-purpose tool for workspace management.

Two Chat Types

• chat — Basic AI conversation with no file context from the workspace index. Use for general questions only.
• chat_with_files — AI grounded in your files. Two mutually exclusive modes for providing file context:
  • Folder/file scope (RAG) — limits the retrieval search space. Requires intelligence enabled; files must be in ready AI state.
  • File attachments — files read directly by the AI. No intelligence required; files must have ai.attach: true in storage details (the file must be a supported type for AI analysis). Max 20 files, 200 MB total.

Auto-promotion: If you create a chat with type=chat but include files_scope, folders_scope, or files_attach, the system automatically promotes the type to chat_with_files. You don't need to worry about setting the type exactly right — the intent is unambiguous when file parameters are present.

Both types augment answers with web knowledge when relevant.

File Context: Scope vs Attachments

For chat_with_files, choose one of these mutually exclusive approaches:

Scope parameters (REQUIRES intelligence — will error if intelligence is off):

• folders_scope — comma-separated nodeId:depth pairs (depth 1-10, max 100 subfolder refs). Defines a search boundary — the RAG backend finds documents within scoped folders automatically. Just pass folder IDs with depth; do not enumerate individual files. A folder with thousands of files and few subfolders works fine.
• files_scope — comma-separated nodeId:versionId pairs (max 100). Limits RAG to specific indexed files. nodeId is required; versionId is required in the pair format but will be auto-resolved to the node's current version if left empty (e.g., nodeId: with nothing after the colon). Get versionId from the file's version field in storage action list or details responses.
• If neither is specified, the default scope is the entire workspace (all indexed documents). This is the recommended default — omit scope parameters unless you specifically need to narrow the search.

Attachment parameter (no intelligence required):

• files_attach — comma-separated nodeId:versionId pairs (max 20, 200 MB total). nodeId is required; versionId will be auto-resolved to the current version if left empty. Files are read directly, not via RAG. FILES ONLY: passing a folder nodeId returns a 406 error. To include folder contents in AI context, use folders_scope instead (requires intelligence). Only files with ai.attach: true in storage details can be attached — check before using.

Do not list folder contents and pass individual file IDs as files_scope when you mean to search a folder — use folders_scope with the folder's nodeId instead. files_scope is only for targeting specific known file versions.

Scope vs attach: files_scope and folders_scope narrow the RAG search boundary and require workspace intelligence to be enabled — they will error on non-intelligent workspaces. files_attach sends files directly to the AI without indexing and works regardless of intelligence setting, but accepts only file nodeIds (not folders).

files_scope/folders_scope and files_attach are mutually exclusive — sending both will error.

Intelligence and AI State

The workspace intelligence toggle (see Workspaces above) controls whether uploaded documents and code files are auto-ingested, summarized, and indexed for RAG. When intelligence is enabled, each file has an ai_state indicating its readiness:

Only files with ai_state: ready are included in folder/file scope searches. Check file state via storage action details with context_type: "workspace".

Attachability — the ai.attach Flag

File nodes in storage list/details responses include an ai object with three fields:

Before using files_attach, check that ai.attach is true. A file is attachable when its type supports AI analysis (documents, code, images, PDFs, spreadsheets, etc.) or when it already has a summary from prior processing. Files with ai.attach: false (unsupported formats, corrupt files, or files still processing) will be rejected by the API.

This flag is independent of the workspace intelligence setting — a file can have ai.attach: true even when intelligence is off.

When to enable intelligence: You need scoped RAG queries, cross-file search, auto-summarization, or a persistent knowledge base.

When to disable intelligence: The workspace is for storage/sharing only, or you only need to analyze specific files via attachments. Saves credits (ingestion costs 10 credits/page).

Even with intelligence off, chat_with_files with file attachments still works for files with ai.attach: true.

How to Phrase Questions

With folder/file scope (RAG): Write questions likely to match content in indexed files. The AI searches the scope, retrieves passages, and cites them.

• Good: "What are the payment terms in the vendor contracts?"
• Good: "Summarize the key findings from the Q3 analysis reports"
• Bad: "Tell me about these files" — too vague, no specific content to match
• Bad: "What's in this workspace?" — cannot meaningfully search for "everything"

**With file attachmen

…(truncated)