Skip to main content
Glama
masoudroot
by masoudroot

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OP_MCP_API_KEYNoAPI key for the MCP server. Used in Docker with `-e OP_MCP_API_KEY=<redacted>` or via the `--api-key SECRET` command-line option for streamable-http transport.

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
searchB

Search Masoud's Persian writing/editing vault. Returns ranked notes with snippets.

read_noteA

Read a full note from the vault by its id (as returned by search).

map_vaultB

The vault's section tree (numbered sections) with note counts.

reindexA

Rebuild the search index (run after notes are added/edited).

rulingB

Get the vault's short editorial ruling for a question/doubt.

Searches the vault, takes the best note, and returns its short ruling (پاسخ کوتاه / نکتهٔ ویرایشی / قاعده یا سازوکار) with the note id. Use this as the virtual editor's verdict before finalizing Persian text.

rule_packA

Build the compact «بستهٔ قاعده» checklist for a Persian writing task.

task_type is one of: گزارش رسمی، ایمیل اداری، لندینگ، مقاله، کپشن، نامهٔ اداری، پروپوزال، خبر، مصاحبه، متن وب، پست شبکهٔ اجتماعی، جواب چت. (Any other value is used as a free-form search query.) Runs seed queries through the vault, keeps only status=verified notes, and returns up to max_rules items as «عنوان: حکم کوتاه». This is step 2-3 of the «حالت کامل» pipeline in the Persian OS.

deep_rulesA

Build the full multi-dimensional checklist for deep Persian editing.

General-purpose (not n8n-specific): any agent calls this once, then runs the deep-edit loop itself —

  1. edit the text against checklist (all rules),

  2. review the edited text rule-by-rule, list remaining issues as JSON,

  3. fix only those issues; repeat 2-3 until clean (max ~4 passes),

  4. final read-through for rhythm, typos, native ear. Combines the task-type rule_pack with the five fixed editorial dimensions (نیم‌فاصله، نشانه‌گذاری، جمله، واژه، لحن); dedupes by note id. Returns checklist as a ready-to-paste string plus structured rules.

smart_rulesA

Diagnose Persian text, then build a tailored deep-edit checklist.

Smarter than deep_rules: instead of a fixed checklist, the text is first scanned for editorial risk signals (long sentences, bureaucratic fossils, Arabic chars, Latin punctuation, ZWNJ issues, quotes, numbers, cliches, repetition, ...). Rules are then pulled for the issues actually present, ordered by signal weight; every rule carries why (the evidence that selected it). Layer 1 is always the task-type rule_pack. General-purpose: any agent runs the edit -> review loop itself.

mechanical_passA

Deterministic mechanical fix + verification gate for Persian text.

Fixes what needs no judgment (Arabic ي/ك, Latin , ; ? %, straight quotes, ZWNJ on می/نمی, spacing) and proves the result: remaining lists any mechanical issue left, clean is true only when none remain. Use it as the first step (so the LLM works on a clean base) and as the final gate (so nothing ships with mechanical errors). Ambiguous cases (em/en dashes) are flagged in remaining, never guessed.

verify_regressionA

Objective regression gate: every problem signal diagnosed in the input text must be gone in the output text.

Pure diagnose() comparison, no LLM. Returns resolved/remaining lists and a boolean pass. This is the pipeline's proof of work — "everything we detected, we fixed."

diff_reportB

Deterministic change ledger: every span the pipeline changed.

Word-level diff with context. Lets any human audit exactly what the system did to the text, without trusting the model's own account.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 11 tools

Disambiguation3/5

The three rule-building tools (rule_pack, deep_rules, smart_rules) overlap heavily — all produce editing checklists for Persian text, and the distinctions (compact vs full vs diagnostic-driven) are subtle enough that an agent could easily misselect. Similarly, search, ruling, and rule_pack all query the same vault, with boundaries explained only in prose. The mechanical_pass/verify_regression/diff_report trio is more clearly separated by their distinct gate/ledger roles.

Naming Consistency4/5

All names are lowercase snake_case with no camelCase mixing, which is a solid baseline. However, the pattern shifts between verb_noun (read_note, map_vault, verify_regression, diff_report) and bare noun/verb forms (search, reindex, ruling), so the convention is mostly but not fully predictable.

Tool Count4/5

Eleven tools is a reasonable scope for a Persian editing pipeline plus vault access. It is slightly heavy given that three of them (rule_pack, deep_rules, smart_rules) occupy nearly the same slot, suggesting some consolidation is possible, but nothing is wildly out of range.

Completeness4/5

The editing pipeline is well-covered end to end: diagnose (smart_rules), fix (mechanical_pass), verify (verify_regression), and audit (diff_report), plus vault access via search/read_note/map_vault/reindex. The vault side is read-only with no note creation or update, but that may be intentional if notes are authored elsewhere, so the gap is minor.

Maintenance

ActivityNo data
ResponsivenessNo issues