Skip to main content
Glama
Sign In

Fastero

by com.fastero
OverviewDiscussionsAdmin

Write Python file

fastero_write_python_file
DestructiveIdempotent

Create or overwrite one text file in a Python project; the answer does not say which it was. Pass the file text; it is encoded for transport. Each run reads the latest version. In a local project every stored file goes into each run; in one linked to a repository only the entrypoint file and requirements.txt (or .in) written here reach a run, and nothing is committed to the repository. For a notebook’s cells, fastero_write_notebook; for a Streamlit app’s files, fastero_write_streamlit_file.

Input Schema

NameRequiredDescriptionDefault
pathYesPath inside the project, e.g. 'main.py' or 'src/report.py'; folders in it need no creating. A local project runs 'main.py' by default.
contentYesThe file text, which may be empty. Replaces the file at that path entirely.
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. Changed4 schema fields changed
    • changedInput schema / properties / content / description
      Previous value: -"The file text. Replaces the file at that path entirely."New value: +"The file text, which may be empty. Replaces the file at that path entirely."
    • changedInput schema / properties / path / description
      Previous value: -"Path inside the project, e.g. 'main.py' or 'src/report.py'. A local project runs 'main.py' by default."New value: +"Path inside the project, e.g. 'main.py' or 'src/report.py'; folders in it need no creating. A local project runs 'main.py' by default."
    • 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.1/5.0
Behavior4/5

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

Annotations already flag readOnlyHint=false, destructiveHint=true, idempotentHint=true, but the description adds real value beyond them: it warns the response does not indicate whether the file was created or overwritten, notes the content is encoded for transport, and explains that each run reads the latest version and that only the entrypoint plus requirements files reach a run in a repository-linked project (with nothing committed). This environment-dependent behavior is exactly the kind of disclosure annotations cannot carry.

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?

Purpose is front-loaded in the first clause, and each sentence carries information (overwrite ambiguity, encoding, run semantics, project-type routing, sibling alternatives). The phrasing is a little choppy and the mid-sentence clause about the answer is slightly awkward, but nothing is padding.

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

Completeness4/5

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

For a four-parameter destructive mutation with no output schema, the description covers the important agent-facing questions: overwrite semantics, no create/overwrite signal in the response, encoding, and environment-specific run/commit behavior. Remaining gaps (concurrency, permissions) are minor.

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?

Schema description coverage is 100%, so all four parameters (path, content, projectId, pythonProjectId) are already documented, including that content replaces the file entirely. The description adds only marginal detail (transport encoding of the file text), so the baseline 3 is appropriate.

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?

States a specific verb (create/overwrite) and resource (one text file in a Python project), and explicitly names the sibling tools it is not (fastero_write_notebook, fastero_write_streamlit_file). An agent can distinguish it from related write tools 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 Guidelines4/5

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

Explicitly routes to alternatives for notebooks and Streamlit apps, and gives the context that behavior differs between local projects and repository-linked projects. It does not, however, state when this tool should not be used (e.g. binary/non-text content, or its relationship to upload_file/replace_streamlit_files), so the guidance is strong but not exhaustive.

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