Skip to main content
Glama
jansc4
by jansc4

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
files_file_hashA

Full SHA1 of the file's contents — a stable identifier independent of the file path.

files_find_filesA

Finds files matching a pattern (e.g. '*.epub') in a folder. Returns a list of paths — the typical 'producer' for for_each steps in run_pipeline: find, then do something with each result.

files_preview_opA

Preview of a SINGLE delete/move operation — changes nothing on disk, just checks whether the file exists and how big it is. Use with for_each to check many files at once before execute_op.

files_execute_opA

Executes a SINGLE delete/move operation. Requires confirm='EXECUTE' — without it, nothing happens. Logs every operation to log_path. Use with for_each (confirm and log_path shared in args across all items) to run on many files in one pipeline step — a single 'EXECUTE' in the step still gates the whole series, just like it used to gate the whole batch.

files_read_fileA

Reads a text file, optionally windowed by line range (start_line, max_lines) and/or capped by max_chars. total_lines tells you how big the file is, so you know whether/how to window a large one. Errors clearly on non-text files instead of returning garbage. Pair with for_each + build_prompts + ask_llm to summarize many files with a cheap local model instead of spending the calling agent's own context on the raw text.

files_write_fileA

Writes text to a file. mode='overwrite' replaces the whole file (creating it if missing); mode='append' adds to the end. Requires confirm='EXECUTE'. Creates the parent folder if missing. path and content are separate arguments (not one dict like db_execute's params) so a for_each step can omit item_arg and spread a list of {"path": ..., "content": ...} dicts directly as calls to this.

meta_get_metadataA

Universal file metadata: epub (DC/calibre), audio/m4b (tags + duration), PDF, DOCX. Always includes path/name/size/type; the rest of the fields depend on the type and are flattened (no nesting).

llm_build_promptsA

Fills a template (Python str.format) with each item in a list. A step between a producer and ask_llm in for_each — builds N full prompts without the agent having to type them out by hand. Plain items (strings, numbers) fill a positional '{}' placeholder; dict items (e.g. read_file's {"path":..., "content":...}) fill named placeholders like '{content}' or '{path}' instead.

llm_ask_llmA

Short query to the local model — for quick, simple decisions/ classification inside a pipeline. Use with for_each after build_prompts to ask about many items at once. model defaults to None, meaning: ask the server what's already loaded (/v1/models) and use that, instead of requesting a specific model by name — avoids forcing a model swap or a second model loading into RAM when something else (e.g. LM Studio Bionic) is already serving a different model on the same port. Pass an explicit model to override this.

fs_analyze_folderB

Breakdown of a folder by file extension (count/size/%) + a structure tree. Skips dependency folders (node_modules, .venv, etc.) by default.

db_schemaA

Lists tables and their columns in a SQLite database — orientation before writing queries. Does not create the file if it's missing.

db_queryA

Runs a single read-only SELECT query. Use params instead of formatting values into the sql string — a list for '?' positional placeholders, or a dict for ':name' named placeholders. The dict form is what makes for_each useful here: a for_each step with item_arg='params' over a list of row-dicts (e.g. from get_metadata) binds each dict directly — extra keys not referenced by the sql are simply ignored.

db_executeA

Runs a single SQL statement that isn't SELECT — CREATE TABLE, INSERT, UPDATE, DELETE, ALTER, DROP. Requires confirm='EXECUTE'. Creates the database file (and its parent folder) if it doesn't exist yet — this is how you create a new database: CREATE TABLE against a path that doesn't exist yet. One statement per call. params: a list for '?' positional placeholders, or a dict for ':name' named placeholders — write a whole row with one call by pairing a for_each step (item_arg='params') over a list of row-dicts with an INSERT using ':name' placeholders matching the dict's keys. confirm/log_path go in args, shared across every item in for_each — one 'EXECUTE' in the step still gates the whole series. Logs every statement to log_path.

run_pipelineA

Runs a list of steps in order. Each step: a block name from REGISTRY, args, optionally save_as (remember the result under a name) and for_each (run the block once per item in a list from an earlier result, referenced as '@name.field'). For each item, either item_arg names the one argument it fills, or — if item_arg is omitted and the item is itself a dict — its keys are spread directly as keyword arguments (for blocks that take several values per call, e.g. write_file's path+content). The result of a for_each step is a list of dicts pairing each item's identifying fields with the block's output — otherwise there'd be no way to tell which result belongs to which item. A step that raises an exception doesn't stop the rest — ok=False + error land in that step's result.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 14 tools

Disambiguation5/5

Each tool has a clearly distinct purpose, and the domain prefixes (files_, db_, llm_, fs_, meta_) make separation immediate. Even the closely paired preview/execute file operations are unambiguous, and read_file vs get_metadata vs analyze_folder are clearly delineated.

Naming Consistency4/5

Names mostly follow a predictable prefix + verb_noun pattern and are consistently snake_case. Minor deviations like db_schema, files_file_hash, and run_pipeline (no prefix) break the pattern slightly, but the overall convention remains readable and navigable.

Tool Count5/5

14 tools is well within the ideal range, and each tool earns its place by covering a distinct operation: file I/O, file operations, DB access, LLM prompting, metadata, folder analysis, and pipeline orchestration. The count feels proportionate to the server's broad but coherent scope.

Completeness4/5

The core pipeline lifecycle is well covered: producing items, processing them with LLM/DB/files, and orchestrating for_each steps. Minor gaps exist, such as no file copy operation and no multi-statement transaction support in db_execute, but agents can work around these without major dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues