Skip to main content
Glama

Write Streamlit app file

fastero_write_streamlit_file
DestructiveIdempotent

Create or replace one file of a Streamlit app, leaving its other files as they are; fastero_replace_streamlit_files replaces the whole set instead, deleting what it leaves out, and fastero_get_streamlit_app reads the current files. path is the folder inside the app ('.' for the top level) and name the file name; the top-level app.py is the file the platform runs. A running app picks up the change in about 5 seconds; a changed requirements.txt applies on the next start, which fastero_run_streamlit_app makes. This tool refuses a Python file that calls socket., subprocess., os.setuid, exec( or eval( (which includes df.eval and pd.eval), and a file whose name ends in .exe, .bat, .sh, .conf, .key, .sql, .php, .msi, .com or .dll. An app imported from Git keeps the edit across its starts until it's sent to its repository as a pull request, or discarded, from the app's workspace. Returns written, the app's new version and the file's path and name. Owners, admins and editors of the project can write files.

Input Schema

NameRequiredDescriptionDefault
nameYesThe file's name with its extension, such as 'app.py' or 'requirements.txt': no slashes, and not starting with a dot.
pathNoFolder inside the app; '.' (the default) is the top level.
appIdYesA Streamlit app’s id, from fastero_list_streamlit_apps.
contentYesThe whole file text, replacing any file of that path and name.
projectIdYesThe project’s id, from fastero_list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / content / description
      Added value: +"The whole file text, replacing any file of that path and name."
    • addedInput schema / properties / name / description
      Added value: +"The file's name with its extension, such as 'app.py' or 'requirements.txt': no slashes, and not starting with a dot."
  2. Changed2 schema fields changed
    • addedInput schema / properties / appId / description
      Added value: +"A Streamlit app’s id, from fastero_list_streamlit_apps."
    • addedInput schema / properties / projectId / description
      Added value: +"The project’s id, from fastero_list_projects."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare non-read-only, idempotent, destructive. The description adds far more: ~5 second hot reload, requirements.txt applying only on next start via fastero_run_streamlit_app, an explicit list of refused Python calls and blocked file extensions, Git-imported apps persisting the edit until PR or discard, and the permission levels that can write. This is exactly the context 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?

Front-loaded with the core action and the sibling routing, then constraints, then return value and permissions — a sensible order. It is dense with semicolon-chained clauses that are hard to parse in one pass, but essentially no sentence is filler.

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?

No output schema exists, and the description compensates by stating the return payload (written, new app version, file path and name). Combined with validation rules, timing, permissions, and persistence behavior, an agent has everything needed to call it correctly and to predict failure modes.

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%, so the baseline is 3; the description nevertheless adds semantics the schema lacks — that path is a folder with '.' meaning top level, that name is the file name, and that top-level app.py is the file the platform actually runs. It also clarifies content replaces the whole file, though it does not detail the projectId/appId provenance beyond what the schema already says.

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 ('Create or replace one file of a Streamlit app') and immediately scopes it against siblings: fastero_replace_streamlit_files (whole set) and fastero_get_streamlit_app (read). An agent can distinguish it from every nearby tool 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 both alternatives and the condition that selects each: whole-set replacement belongs to fastero_replace_streamlit_files (which deletes omitted files), reads belong to fastero_get_streamlit_app. It also signals the requirements.txt case is better served by a restart path, effectively an exclusion.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.