Skip to main content
Glama
fulcradynamics

Fulcra MCP Server

by fulcradynamics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Open File Manager

open_file_manager
Read-only

Opens a file manager for Fulcra files so users can upload files from their computer or download existing files, including large spreadsheets, from a chosen path.

Instructions

Show the user a file manager for their Fulcra files, where they can upload files from their computer (any type or size, such as spreadsheets) and download files. Use it when the user wants to upload or download files.

Input Schema

NameRequiredDescriptionDefault
pathNoThe folder or exact file to open (default "/")./
fulcra_useridNoOptional file owner. Shared files open read-only; access still requires a separate file share.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.18.7
    • addedInput schema / properties / fulcra_userid
      Added value: +{
+  "description": "Optional file owner. Shared files open read-only;\naccess still requires a separate file share.",
+  "type": "string"
+}
    • changedInput schema / properties / path / description
      Previous value: -"The folder to open (default \"/\")."New value: +"The folder or exact file to open (default \"/\")."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. Addedv1.2.4

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds that this surfaces an interactive UI to the user and accepts any file type or size, which is useful context beyond the annotations. However, it omits the key behavioral trait an agent needs: whether the call blocks pending user interaction and what it returns (a path? a handle?) once the user uploads or downloads.

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?

Two front-loaded sentences, no filler. The parenthetical 'any type or size, such as spreadsheets' is a slightly incidental detail but it does convey a real capability, so it earns its place.

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 2-param, no-output-schema tool with annotations, the description covers what the tool is but not the interaction model, which is the crux of a UI-opening tool: whether it blocks, what the agent should do afterwards, and how the resulting files relate to list_files. Adequate but with a clear gap for this tool's complexity archetype.

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%, and the schema already explains 'path' (folder or exact file, default "/") and 'fulcra_userid' (file owner, shared files are read-only, separate share still required). The description adds nothing about either parameter, so the baseline 3 applies.

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: 'Show the user a file manager for their Fulcra files', and adds scope (upload from computer, download). It does not name or distinguish itself from the many headless file siblings (list_files, read_file, write_file, start_file_upload, upload_file_chunk), so an agent must infer that 'show the user' means an interactive UI rather than a programmatic operation.

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?

'Use it when the user wants to upload or download files' gives a trigger condition, but it overlaps directly with start_file_upload/upload_file_chunk/write_file/read_file, which also serve upload and download intents. No exclusion or preference rule is given (e.g. 'use this only for interactive/bulk/ad-hoc transfers; use upload_file_chunk for scripted uploads'), leaving a real misroute risk.

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