Skip to main content
Glama
Sign In
MCP-Bifrost

MCP-Bifrost

by ArnauFerma
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

create_file

Writes a new source file without overwriting, optionally using an existing sibling as a structural template to match codebase conventions. Optionally runs a verification command.

Instructions

Write a new source file. Never overwrites. Pass model_from to generate BY ANALOGY: the worker is handed an existing sibling as a structural exemplar and traces its shape, naming and error handling rather than inventing its own. Where a codebase already has many files of one kind, this is by far the most reliable way to add another — the worker does not need to know your conventions, it needs to copy them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file_path": "<file_path>",
      "instruction": "<instruction>"
    },
    "name": "create_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
verifyNoOptional shell command run after the file is written, cwd the repo root — e.g. 'pytest tests/test_foo.py -q'. Non-zero exit deletes the file and returns the command's output instead of reporting success — catches a syntactically fine file that is still wrong, which no gate before this can see.
file_pathYes
model_fromNoPath to an existing file to use as the structural exemplar. Strongly recommended.
instructionYes
allow_secretsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the non-destructive guarantee ('Never overwrites') and the analogy-generation behavior of model_from, plus the existence of verification. It does not describe required permissions, what happens to the file on failure outside the verify path, or the return shape, leaving real gaps for a write tool.

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 correctly: the core action and the never-overwrites guarantee come first, then the model_from explanation. The closing clause about the worker not needing to know conventions is somewhat rhetorical padding, but the overall size is proportionate to the tool's unusual semantics.

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

Completeness3/5

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

For a five-parameter write tool with no annotations and no output schema, the description covers the main creation and analogy flow well but leaves allow_secrets unexplained and says nothing about failure/side-effect behavior beyond verify. Adequate for the happy path, incomplete around safety-relevant parameters.

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 coverage is 40%, so the description must compensate, and it does well for model_from — explaining the analogy mechanism far beyond the schema's one-liner. However, allow_secrets is left completely undocumented in both the schema and the description, which is a notable risk for a flag governing secret material, and instruction/file_path are unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Write a new source file') and immediately constrains it with 'Never overwrites', which separates it from the mutation-siblings like insert_symbol and fix_symbol that edit existing files. It never names those siblings explicitly, so the distinction must be inferred rather than read.

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

Usage Guidelines3/5

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

Gives strong conditional guidance for one path ('where a codebase already has many files of one kind', use model_from), but says nothing about when to reach for create_file versus insert_symbol or fix_symbol for the same file, and gives no prerequisites or ordering advice. Usage context is implied by the never-overwrites constraint rather than stated.

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

Deploy Server

Other Tools