Skip to main content
Glama
Sign In

Fastero

by com.fastero
OverviewDiscussionsAdmin

Read Python file

fastero_read_python_file
Read-only

Read one file of a Python project: a picture (PNG, JPEG, GIF or WebP), such as a chart a run saved in outputs/, comes back as an image with its mimeType, bytes and source; anything else as text. Text returns content, decoded as UTF-8, and source: local for a file stored in Fastero (written here, or saved by a run), git for one read from the linked repository's branch; a stored file is read in place of the repository's at the same path. Read a file here before fastero_write_python_file, which replaces the whole file; the path, relative to the project's root, comes from fastero_list_python_files. Uploaded project files such as spreadsheets are read with fastero_read_file, and notebooks with fastero_read_notebook. A file over 1,000,000 bytes is refused, with its size, rather than cut, since writing a cut copy back would lose the rest, and a path outside the project is refused. Any project member, viewers included, can read it.

Input Schema

NameRequiredDescriptionDefault
pathYesPath inside the project, e.g. 'main.py' or 'src/report.py'.
projectIdYesThe project’s id, from fastero_list_projects.
pythonProjectIdYesA Python project’s id, from fastero_list_python_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / projectId / description
      Added value: +"The project’s id, from fastero_list_projects."
    • addedInput schema / properties / pythonProjectId / description
      Added value: +"A Python project’s id, from fastero_list_python_projects."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond readOnlyHint: text is decoded as UTF-8, a 'source' field distinguishes local vs git and stored files shadow repository ones, a 1,000,000-byte file is refused with its size rather than truncated, and out-of-project paths are rejected. Permission scope ('any project member, viewers included') is also stated.

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?

Front-loaded with purpose and return shapes, and every clause carries information (limits, source semantics, alternatives). It is a single very dense paragraph with long run-on sentences, which costs some readability, but little could be cut without losing behavior an agent needs.

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?

There is no output schema, yet the description explains both return shapes and the fields they carry (mimeType, bytes, source, content). Combined with the size and path restrictions, an agent has everything needed to call it and interpret the result.

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 already 100%, so the baseline would be 3, but the description adds real meaning: the path is relative to the project root, comes from fastero_list_python_files, and paths outside the project are refused. That is more than the schema's bare example strings convey.

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?

Opens with a specific verb and resource ('Read one file of a Python project') and immediately delineates the two return shapes (image vs text). It explicitly separates itself from fastero_read_file and fastero_read_notebook, so an agent can route correctly without opening a schema.

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?

Names the alternatives and the conditions selecting them: uploaded files go to fastero_read_file, notebooks to fastero_read_notebook. It also gives the sequencing rule ('Read a file here before fastero_write_python_file') and where to get the path (fastero_list_python_files).

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

All Fastero toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources