What can you do with this server?

File AI is a read-only document awareness server that lets agents understand local file contents without parsing file internals. * Analyze documents (doc_analyze): Parse a local file into a structured index containing a profile, anchors, outline, blocks, and chunks — with optional chunking configuration (size, overlap, max text length per anchor). * Read document content (doc_read): Retrieve specific blocks, chunks, or anchors from a cached document index by index ID, block ID, chunk ID, or anchor ID. * Search document content (doc_search): Run keyword searches across cached document blocks, returning excerpts tied to stable anchors, with optional case sensitivity, result limits, and context character controls. * Retrieve contextual windows (doc_context): Fetch nearby blocks surrounding a specific anchor or query match, with configurable before/after block counts. * List supported formats (doc_list_formats): View all 206+ formats recognized by the Flyfish File Viewer core, their renderer capabilities, and File AI's extraction coverage. * Access document resources: Directly access a document's profile (doc://{indexId}/profile), outline (doc://{indexId}/outline), and chunks (doc://{indexId}/chunks) as MCP resources. * Wide format support: Full structured extraction for PDF, DOCX, XLSX/CSV, PPTX, EML, Markdown, JSON, code, and archive manifests; best-effort metadata for CAD, 3D, media, image, geospatial, and other formats. * Anchor-based citations: Every content block carries a stable anchorId (page, slide, worksheet, row range, etc.) for grounded document citations. * Read-only: Original source documents are never modified.

How do I use File AI?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@File AI Analyze the quarterly report.docx and show its outline" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

File AI

by flyfish-dev

Overview Schema Related Servers Score Discussions

TypeScript

Local

File AI

Read-only document awareness MCP server for agents. File AI uses Flyfish File Viewer core as the source of truth for format recognition, then turns local files into a stable profile, anchors, blocks, chunks, outline, search results, and contextual snippets so an agent can understand document content without reverse-engineering PDF, OOXML, spreadsheet, email, or archive internals.

MCP Registry name: io.github.flyfish-dev/file-ai

Install

Use it directly with npx:

npx -y @flyfish-dev/file-ai

Or install it globally:

npm install -g @flyfish-dev/file-ai
file-ai --transport stdio

Related MCP server: RAG Document Server

MCP Client Config

Stdio:

{
  "mcpServers": {
    "file-ai": {
      "command": "npx",
      "args": ["-y", "@flyfish-dev/file-ai"]
    }
  }
}

Streamable HTTP:

npx -y @flyfish-dev/file-ai --transport http --host 127.0.0.1 --port 8765

Endpoint:

http://127.0.0.1:8765/mcp

Tools

doc_analyze: parse a local file and cache a document index.
doc_read: read blocks, chunks, or anchors from an existing index or path.
doc_search: search cached content with source anchors.
doc_context: retrieve nearby blocks around an anchor or query.
doc_list_formats: list File Viewer core registry formats, all supported extensions, renderer capabilities, and File AI extractor coverage.

Resources

doc://{indexId}/profile
doc://{indexId}/outline
doc://{indexId}/chunks

Supported Files

File AI recognizes formats through @file-viewer/core/headless, currently covering 206 registered extensions. profile.format is therefore aligned with the same renderer selection used by Flyfish File Viewer.

Content extraction is a separate layer. File AI provides structured awareness for text/code/Markdown/JSON, PDF text, DOCX, XLSX/CSV, PPTX, EML, and archive manifests. Other File Viewer renderer-only formats such as CAD, 3D, media, image, geospatial, drawing, ebook, and data assets are still recognized in profile.format; when no structured text extractor exists yet, File AI returns a profile plus best-effort metadata/text and explicit warnings in profile.warnings and profile.extraction.

Every content block carries an anchor such as a page, slide, worksheet, row range, nested path, or byte/text location. Agents should cite returned anchorId values when making document-grounded claims.

Development

pnpm install
pnpm build
pnpm test
pnpm validate:skill

Run locally:

pnpm dev -- --transport stdio
pnpm dev -- --transport http --port 8765

Publishing

The package includes:

npm metadata for @flyfish-dev/file-ai
MCP Registry metadata in server.json
GitHub Actions workflow .github/workflows/publish-mcp.yml

Release flow:

git tag v0.1.0
git push origin v0.1.0

The workflow publishes the npm package first, then publishes io.github.flyfish-dev/file-ai to the official MCP Registry through GitHub OIDC. The repository must have an NPM_TOKEN secret that can publish @flyfish-dev/file-ai.

The server is read-only. It does not mutate source documents.

Available Tools

5 tools

doc_analyzeAnalyze documentB

Parse a local document into a read-only profile, anchors, outline, blocks, and chunks for agent context.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Local file path to analyze.
`refresh`	No	Re-parse even if this path is already cached.
`maxTextLength`	No	Maximum text characters per source anchor before chunking.
`chunkSize`	No	Target chunk size in characters.
`chunkOverlap`	No	Chunk overlap in characters.

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of disclosure. It mentions the output includes a 'read-only profile', which implies the operation is read-only, but it does not explicitly state that the tool does not modify files, nor does it mention any authentication or performance considerations. The behavioral transparency is adequate but not thorough.

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 a single 20-word sentence that front-loads the action and lists the main outputs. Every word adds value; there is no fluff or repetition. It is highly concise and well-structured.

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

Completeness2/5

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

The tool has 5 parameters and no output schema, yet the description does not explain the output structure or how parameters like chunkSize affect the result. Given the complexity and the presence of sibling tools, the description is too brief to be fully complete. An agent would likely need additional context to use the tool effectively.

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?

All 5 parameters have descriptions in the input schema (100% coverage), so the schema already explains them. The description adds no additional meaning or context for parameters beyond what is in the schema. Thus, baseline score of 3 applies.

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 verb 'Parse' and the resource 'local document', and lists the specific output components: read-only profile, anchors, outline, blocks, and chunks. This provides a detailed and distinct purpose compared to sibling tools like doc_read or doc_context.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus alternatives like doc_read or doc_search. It lacks any 'when to use' or 'when not to use' information, leaving the agent to infer context from the tool name alone.

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

doc_contextRead contextual document windowC

Return nearby blocks around an anchor or the first anchors matching a query.

ParametersJSON Schema

Name	Required	Description	Default
`indexId`	No
`path`	No
`anchorId`	No
`query`	No
`before`	No
`after`	No
`limit`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It fails to mention whether the operation is read-only, idempotent, or has side effects. Minimal information beyond the return action.

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?

Single sentence is concise and front-loaded with the primary function. No waste, but could benefit from a bit more structure (e.g., listing parameter roles).

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

Completeness1/5

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

With 7 parameters, no output schema, and no annotations, the description is grossly insufficient. It does not explain return format, default behavior, or error conditions.

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

Parameters1/5

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

Schema description coverage is 0%, leaving all 7 parameters without explanations. The tool description does not add any meaning beyond parameter names (e.g., anchorId vs query, how before/after interact with limit).

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 ('Return') and resource ('blocks') with clear context ('nearby blocks around an anchor' or matching a query). It distinguishes itself from sibling tools like doc_read (reads whole doc) and doc_search (searches tokens).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. It does not state when not to use it, prerequisites, or which sibling to prefer in different scenarios.

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

doc_list_formatsList supported formatsB

List Flyfish File Viewer known formats and document-engine extractors.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for transparency. It only states what the tool lists, but does not disclose behavioral traits such as read-only nature, return format, or any side effects. The description is insufficient for a tool with zero annotation coverage.

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 a single sentence that clearly states the tool's purpose without any verbose or redundant phrasing. Every word adds value, achieving maximum conciseness.

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

Completeness2/5

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

With no output schema and no annotations, the description should explain the return value format (e.g., whether it returns a list of strings or objects). It fails to do so, leaving the agent unsure of what to expect from the tool.

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?

The input schema has no parameters, and schema description coverage is 100% (trivially). According to guidelines, baseline is 3 when coverage is high. The description adds no parameter information, which is acceptable since there are no parameters to describe.

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 the specific verb 'List' and clearly identifies the resource (Flyfish File Viewer known formats and document-engine extractors). It distinguishes the tool from its siblings (doc_analyze, doc_context, doc_read, doc_search) as the only one focused on listing formats and extractors.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, conditions, or scenarios where another sibling tool would be more appropriate.

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

doc_readRead document index contentB

Read blocks, chunks, or anchors from a cached index without inspecting source document internals.

ParametersJSON Schema

Name	Required	Description
`indexId`	No	Cached document index id from doc_analyze.
`path`	No	Analyze this path if indexId is not supplied.
`anchorId`	No
`blockId`	No
`chunkId`	No
`limit`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided; description states read-only operation from cache but omits behavioral details like idempotency, side effects, or prerequisites (e.g., index must exist from doc_analyze).

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?

Single sentence conveys core purpose efficiently. Slightly front-loaded but could benefit from additional context without sacrificing brevity.

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

Completeness2/5

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

Description is insufficient given six parameters, no output schema, and no annotations. Lacks explanation of how to combine parameters (e.g., indexId vs path) or what the return value includes.

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

Parameters2/5

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

Schema coverage is low (33%), and description mentions only general element types (blocks, chunks, anchors) without clarifying parameter relationships or usage logic for the five non-described parameters.

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?

Description clearly states the tool reads blocks, chunks, or anchors from a cached index, distinguishing it from source document inspection. Verb 'Read' and specific resource 'cached index' are explicit.

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

Usage Guidelines3/5

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

Description implies usage when a cached index is available ('without inspecting source internals'), but does not provide explicit when-to-use or when-not-to-use guidance compared to siblings like doc_analyze or doc_search.

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

doc_searchSearch document contentC

Search document blocks and return excerpts tied to stable anchors.

ParametersJSON Schema

Name	Required	Description	Default
`indexId`	No
`path`	No
`query`	Yes
`limit`	No
`contextChars`	No
`caseSensitive`	No

TDQS

C2.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that it returns excerpts but does not mention read-only nature, auth needs, or details like case sensitivity or anchor mechanics.

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

Conciseness3/5

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

Single sentence, front-loaded with verb and resource, but lacks parameter descriptions. Could be expanded without becoming verbose.

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

Completeness2/5

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

With 6 parameters, 0% schema description coverage, no output schema, and no annotations, the description does not provide sufficient context for correct invocation. Agent needs more detail on constructing queries and interpreting anchors.

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

Parameters1/5

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

Schema description coverage is 0%, and description provides no explanation for any of the 6 parameters (indexId, path, query, limit, contextChars, caseSensitive). Agent must rely on schema alone.

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?

Description uses specific verb 'Search' and resource 'document blocks', and mentions returning 'excerpts tied to stable anchors', which clearly distinguishes from siblings like doc_read (full document) or doc_analyze (analysis).

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

Usage Guidelines2/5

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

No explicit guidance on when to use vs alternatives (e.g., doc_read for full retrieval, doc_context for contextual info). Does not mention prerequisites or 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jun 23, 2026
- First observeddoc_analyze
- First observeddoc_context
- First observeddoc_list_formats
- First observeddoc_read
- First observeddoc_search

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: analyze parses documents, context retrieves nearby blocks, list_formats lists supported formats, read reads blocks, and search searches. No overlapping functionality.

Naming Consistency5/5

All tools follow a consistent 'doc_verb' pattern (doc_analyze, doc_context, doc_list_formats, doc_read, doc_search), making the naming predictable and easy to understand.

Tool Count4/5

With 5 tools, the server is well-scoped for a document analysis agent. While slightly minimal, each tool earns its place and the count is reasonable for the domain.

Completeness4/5

The tool surface covers core operations: parsing, reading, searching, and context retrieval. Missing features like document listing or updates, but for a read-only analysis server, it is largely complete.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
Needle
com.needle-ai.mcp
The Needle MCP server enables semantic search on documents stored in files like PDFs, DOCX, and XLSX by connecting AI applications to external data sources. It provides capabilities to create and manage document collections, perform natural language searches on stored content, and retrieve relevant information without requiring exact keyword matches.
RAG Systems Search File Systems
2
agentverse
io.github.doc2mcp
MCP server for agentverse documentation, generated by doc2mcp.
Agent Orchestration Documentation Access
24
ORANO MCP Server
io.github.infotik
Read-only MCP server exposing a user ORANO library to their own AI agent.
1

Related MCP Servers

Docalyze
File Systems Image & Video Processing
LunarPerovskite
A
license
B
quality
D
maintenance
An MCP server that lets AI assistants read and visually analyze local documents — PDFs, Excel spreadsheets, CSV files, Word documents, PowerPoint presentations, and images.
Updated 4 months ago (2026-04-28 15:33 UTC)
4
66
MIT
RAG Document Server
RAG Systems Vector Databases Search
Vamshi9415
A
license
Not graded
quality
D
maintenance
A deterministic MCP server for document processing and retrieval that enables AI agents to process, chunk, and vector-search documents without an LLM.
Updated 4 months ago (2026-04-29 12:54 UTC)
MIT
docs-mcp-server
Documentation Access Developer Tools
DewminK
F
license
Not graded
quality
B
maintenance
MCP server that exposes one or more documentation folders (Markdown, MDX, TXT) to AI agents, enabling listing, reading, and searching of documentation files.
Updated 2 months ago (2026-07-11 20:48 UTC)
-
skill-mcp
Documentation Access RAG Systems
jacobragsdale
F
license
Not graded
quality
C
maintenance
An MCP server that serves company documentation from a Markdown folder, exposing read-only search and fetch tools for agents to discover and retrieve authoritative documents.
Updated a month ago (2026-08-05 01:14 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/flyfish-dev/file-ai'

If you have feedback or need assistance with the MCP directory API, please join our Discord server