obper-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OP_MCP_API_KEY | No | API 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 —
|
| 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 |
| 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: |
| 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 |
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
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.
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.
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.
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.