Skip to main content
Glama
mondaycom

monday MCP Server

Official
by mondaycom
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Fetch File Content

fetch_file_content
Read-onlyIdempotent

Extract text from files attached to monday.com board items for reading, summarizing, or analyzing content.

Instructions

Fetch and extract the text content from a file stored in a monday.com files column.

Use this tool when you need to read, summarize, or analyze the content of files attached to board items. Provide the item ID and column ID from the get_board_items_page response — the column value will be a URL like "https://monday.com/protected_static/..." indicating a file is present (null means no file).

PROACTIVE USE: If you retrieve board items and notice a files column with a non-null value (a URL), consider fetching its content if it could help answer the user's question — don't wait to be explicitly asked.

Supported file types and what is returned:

  • Text files (.txt, .md, .csv, .json): raw text content

  • Word documents (.docx): extracted text content

  • PDF files (.pdf): extracted text content

  • Excel files (.xlsx, .xls): extracted text content per sheet

  • Images (.png, .jpg, .gif, .webp, .svg, .bmp, .ico): returns the public URL so you can view or analyze the image directly

Text responses include a total_length field. If has_more is true, the content was truncated — you can call this tool again with next_offset if you need the remaining content.

When to use:

  • User asks to summarize, read, or analyze the content of a file in a files column

  • User asks questions about what is inside a file (e.g., "what does the PDF say?")

  • User wants to extract data from a CSV or Excel file attached to a board item

  • A board item has a files column with a non-null value and the user's question may be answered by its content — even if the user didn't explicitly ask to read the file

When NOT to use:

  • The files column value is null (no file uploaded for that item)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
item_idYesThe ID of the item that contains the file. Obtained from get_board_items_page results.
column_idYesThe ID of the files column containing the file. Obtained from the board schema.
file_nameNoOptional file name hint used to determine the file type when the asset name is ambiguous. Include the extension (e.g. "report.pdf").
offsetNoCharacter offset to start reading from. Use when a previous response indicated the content was truncated (has_more: true). Defaults to 0.

Tool Definition Quality

A5/5.0
Behavior5/5

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

Annotations already indicate readOnly, non-destructive, idempotent. The description adds behavioral details beyond annotations: supported file types, return formats per type, truncation behavior with has_more/next_offset, and that images return a public URL. No contradictions.

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?

Well-structured with clear sections: purpose, proactive use, supported types, response details, usage criteria. Every sentence adds value and is appropriately positioned. Length is justified by complexity.

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?

Despite having no output schema, the description comprehensively explains return values (text content, total_length, has_more, next_offset, or public URL for images). All parameters are covered with usage context. Complete for the tool's functionality.

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

Parameters5/5

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

Schema descriptions cover all parameters (100% coverage). The description adds meaning by explaining how to obtain item_id and column_id from get_board_items_page, the purpose of file_name hint for ambiguous types, and offset for truncation handling.

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 'fetch' and the resource 'text content from a file stored in a monday.com files column'. It distinguishes from sibling tools by specifying when to use it for reading file contents, as opposed to other read tools like get_board_items_page.

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?

Provides explicit 'When to use' and 'When NOT to use' sections, including proactive usage guidance. The description gives clear context for when this tool should be selected over alternatives.

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

Install Server

Other Tools

Latest Blog Posts

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/mondaycom/mcp'

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