Ruflo GPT
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RUFLO_CODEX_STATE_DIR | No | Overrides the root directory for local state storage. The default local store is `~/.local/share/ruflo-codex/state/projects/<project-path-hash>/`. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| codex_statusA | Use to inspect the installed Ruflo/Codex adapter and its project store. Reports actual versions and boundaries. Does not launch agents or modify Codex settings. |
| memory_storeA | Persistent key-value store with vector embedding — survives across sessions and is searchable by meaning, not just by file path. Use for project-scoped persistent memory. Never import personal memory automatically. Data is isolated by project_path; runtime reports actual embedding and storage backend. |
| memory_retrieveA | Read back a value previously stored via memory_store, by exact (namespace, key) — lossless, includes metadata. Use for project-scoped persistent memory. Never import personal memory automatically. Data is isolated by project_path; runtime reports actual embedding and storage backend. |
| memory_searchA | Find stored memories by meaning (vector similarity), not by literal text — finds "JWT auth pattern" when you query "token-based login flow". Use for project-scoped persistent memory. Never import personal memory automatically. Data is isolated by project_path; runtime reports actual embedding and storage backend. |
| memory_deleteB | Remove a stored memory entry by exact (namespace, key). Use for project-scoped persistent memory. Never import personal memory automatically. Data is isolated by project_path; runtime reports actual embedding and storage backend. |
| memory_listA | Enumerate stored memory entries (optionally filtered by namespace/tags) without semantic search. Use for project-scoped persistent memory. Never import personal memory automatically. Data is isolated by project_path; runtime reports actual embedding and storage backend. |
| memory_statsB | Get memory storage statistics including HNSW index status Use for project-scoped persistent memory. Never import personal memory automatically. Data is isolated by project_path; runtime reports actual embedding and storage backend. |
| task_createA | Use when tracking persistent work across Codex sessions: create. Stores task metadata only; does not start or execute an agent. Isolated by project_path. |
| task_statusB | Use when tracking persistent work across Codex sessions: status. Stores task metadata only; does not start or execute an agent. Isolated by project_path. |
| task_listA | Use when tracking persistent work across Codex sessions: list. Stores task metadata only; does not start or execute an agent. Isolated by project_path. |
| task_completeB | Use when tracking persistent work across Codex sessions: complete. Stores task metadata only; does not start or execute an agent. Isolated by project_path. |
| task_updateA | Use when tracking persistent work across Codex sessions: update. Stores task metadata only; does not start or execute an agent. Isolated by project_path. |
| task_assignB | Use when tracking persistent work across Codex sessions: assign. Stores task metadata only; does not start or execute an agent. Isolated by project_path. |
| task_cancelB | Use when tracking persistent work across Codex sessions: cancel. Stores task metadata only; does not start or execute an agent. Isolated by project_path. |
| task_retryB | Use when tracking persistent work across Codex sessions: retry. Stores task metadata only; does not start or execute an agent. Isolated by project_path. |
| task_summaryC | Use when tracking persistent work across Codex sessions: summary. Stores task metadata only; does not start or execute an agent. Isolated by project_path. |
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 16 tools
The memory tools are clearly differentiated by operation (store, retrieve, search, delete, list, stats), but the task tools have overlapping boundaries. task_status, task_summary, and task_list are easy to confuse, as are task_update, task_assign, task_complete, task_cancel, and task_retry. The repetitive templated descriptions provide little help in distinguishing these task operations.
All tool names use consistent snake_case with clear resource prefixes: memory_* and task_* for their domains. codex_status is a minor deviation from the verb_noun pattern but still fits the overall resource_action convention.
Sixteen tools across two substantial domains (persistent memory and task tracking) plus adapter status is reasonable, though the nine task tools feel slightly over-granular for metadata-only operations. The count is not excessive but is near the upper end of a well-scoped set.
The memory surface covers storing, retrieving, searching, deleting, listing, and stats, while the task surface covers creation, updates, status, listing, completion, cancellation, retry, assignment, and summary. Together with codex_status, this provides full lifecycle coverage for the stated domain with no obvious dead ends.