Skip to main content
Glama
openl-tablets

OpenL MCP Server

Official

Read Project File

openl_read_project_file
Read-onlyIdempotent

Read any project file by relative path: retrieve file content (text or binary), metadata, list folder entries, or download folder as ZIP. Supports version and branch pinning.

Instructions

Read any file in a project by its project-relative path — text or binary, and folder listings too. Maps to GET /projects/{projectId}/files/{path}. Behavior by path/params: (1) a FILE path returns its content — UTF-8 text is returned verbatim, binary is returned base64-encoded with metadata (use encoding to force 'utf-8' or 'base64'; default 'auto' detects); (2) a FILE path with view='meta' returns JSON metadata (name, size, extension, lastModified); (3) a FOLDER path (empty string for the root, or a path ending in '/') lists its entries (use recursive, viewMode FLAT/NESTED, extensions, namePattern, foldersOnly); (4) a FOLDER path with download=true returns a ZIP of the folder (base64). Optional 'version' reads a historical revision; 'branch' pins the project branch. Optional byte range (offset/length) is applied client-side AFTER fetching the whole file (the backend does not support partial transfers), so the entire file is loaded into memory; for very large/binary files, bound the RETURNED size with offset/length and read in chunks (a full file's base64 can exceed MCP message limits). Use this to read AGENTS.md, README.md, schemas, manifests, or to inspect/export xlsx rule files.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesProject-relative path to a file or folder (e.g. 'rules/Model.xlsx' or 'rules/'). Empty string (default) or a path ending in '/' lists the project root / that folder; a file path returns the file content.
viewNoFor a file, set to 'meta' to return JSON metadata (name, size, extension, lastModified) instead of the file content. Omit to read content (files) or list entries (folders).
branchNoBranch the project must be on for this operation. Ignored when blank. Fails if the repository has no branches or the project is on another branch. Omit for repository 'local' and non-branch repositories.
fieldsNoComma-separated response fields to return for metadata/listing responses, including nested selection (e.g. 'id,name'). When omitted, the full response is returned.
lengthNoMaximum number of bytes of file content to return starting at 'offset'. Omit for the rest of the file. Byte count, not character count (see the note on 'offset').
offsetNoByte offset to start reading file content from (default 0). NOTE: the backend does not support partial transfers, so the whole file is fetched and then sliced client-side. offset/length are BYTE offsets — a range boundary that lands inside a multi-byte UTF-8 character makes that character decode to U+FFFD (�) at the seam; for exact bytes use encoding='base64'.
versionNoHistorical revision (commit hash) to read. Omit to read the latest revision. Applies to file content/metadata and folder listing/ZIP. An unknown revision yields 404.
downloadNoFor a folder, set true to download the folder and its contents as a ZIP archive (returned base64-encoded). Ignored for files.
encodingYesHow to return file content. 'auto' (default) returns text as UTF-8 and binary as base64; 'utf-8' forces text; 'base64' forces base64. Ignored for metadata/listing responses.auto
viewModeNoFolder listing only: FLAT returns a flat list, NESTED returns a tree (default FLAT).
projectIdYesProject ID returned by backend. Use the exact 'projectId' value from openl_list_projects() response without modification or reformatting.
recursiveNoFolder listing only: include nested resources recursively (default false).
extensionsNoFolder listing only: filter by file extensions without the dot, e.g. ['xlsx','xml'].
foldersOnlyNoFolder listing only: if true, return only folders (default false).
namePatternNoFolder listing only: filter by name (case-insensitive contains match).
response_formatNoResponse format: 'json' for structured data, 'markdown' for human-readable (default), 'markdown_concise' for brief summary (1-2 paragraphs), 'markdown_detailed' for full details with contextmarkdown
Behavior5/5

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

Annotations only provide readOnlyHint and idempotentHint, but description goes far beyond by detailing behavior for files vs folders, encoding modes, client-side slicing, memory implications, and MCP message limit warnings.

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?

Description is verbose but well-structured with numbered scenarios, front-loading the main purpose. Every sentence adds value given the tool's 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?

Without an output schema, the description comprehensively covers return types (content, base64, metadata, listing, ZIP) and error conditions (404 for unknown version), leaving no gaps.

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

Parameters4/5

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

Schema coverage is 100% (baseline 3), but description adds meaningful context beyond schema, such as path behavior for '/' ending, offset/length caveats with multi-byte characters, and auto-encoding detection.

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 reads any file or folder in a project by path, distinguishing it from sibling tools like openl_write_project_file and openl_search_project_files.

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

Usage Guidelines4/5

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

Provides explicit examples of when to use (e.g., reading AGENTS.md, README.md, schemas) and implies alternatives via sibling tools, but lacks explicit when-not-to-use statements.

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/openl-tablets/openl-mcp'

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