fushiguro-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FUSHIGURO_DB | No | Path to the SQLite database used for memory and knowledge index. | ~/.fushiguro/memory.db |
| FUSHIGURO_CATALOG | No | Path to your business's catalog — the custom layer. | <project>/.fushiguro/catalog |
| FUSHIGURO_MIN_SCORE | No | Below this score, no confident router match is made. | 0.12 |
| FUSHIGURO_BASE_CATALOG | No | Path to the packaged catalog. Rarely changed. | <package>/catalog |
| FUSHIGURO_PROJECT_ROOT | No | Project root used to key project-scoped memories. | cwd |
| FUSHIGURO_AMBIGUITY_RATIO | No | Top two agents scoring within this ratio are reported as ambiguous. | 0.85 |
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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| briefA | Assess how much machinery a task deserves, then return either 'handle it yourself', one specialist's system prompt, or a multi-stage plan (planner → executor → tester → reviewer) with intake questions to ask first. Call this before starting any non-trivial task. Respect a 'handle_directly' verdict — spawning a subagent for small work wastes tokens and time. |
| get_stageB | Fetch the system prompt for one stage of a plan returned by |
| list_catalogA | Show catalog entries — agents, skills, knowledge, runbooks, topics, tools, connectors — each tagged base, custom, or base+custom. |
| get_entryA | Fetch the full content of one catalog entry — an agent's prompt, a skill, a runbook with its table of contents, a connector's guardrails. |
| search_knowledgeA | Retrieve passages from the organisation's own documentation. Use for a direct factual lookup. Cite the returned chunk id when you use a passage, and say so plainly when the answer is not in the corpus rather than filling the gap. |
| rememberA | Record a preference, rule, or correction so future briefings honour it. Restating an existing preference reinforces it rather than duplicating; a constraint or correction that contradicts a softer memory retires the old one. Use for standing rules, never for one-off task instructions. |
| recallB | Search remembered preferences, ranked by relevance and how binding they are. |
| forgetA | Permanently delete one memory by id. Use when the user says a preference is wrong or obsolete. |
| record_outcomeA | Tell the router whether the agent it chose was right. This adjusts the term-to-agent weights it consults, so routing improves with use. Call after the user reacts to a subagent's work. |
| statusA | What is loaded: catalog counts by kind and layer, knowledge index size, stored preferences, and any files that failed to parse. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| delegate | Brief the right agent and hand its prompt to a subagent. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| catalog | Every agent, skill, knowledge doc, runbook, topic, tool, and connector. |
TDQS
Scored across 10 tools
Each tool targets a distinct phase or store: planning, stage prompts, catalog browsing, memory CRUD, knowledge search, router feedback, and status. The only mild ambiguity is between recall (personal preferences) and search_knowledge (organizational docs), but the descriptions clearly separate the two corpora.
Tool names are all lowercase and mostly follow an imperative verb style, with clear verb_noun names like get_stage, list_catalog, and record_outcome. Minor deviations like bare 'brief' and the noun 'status' break the pattern slightly but remain readable and predictable.
10 tools is a well-scoped size for an orchestration and memory server; each tool earns its place by covering a distinct concern without redundancy. The count feels intentional rather than bloated or thin.
The surface covers planning, staged execution, catalog lookup, preference memory, knowledge retrieval, and router feedback, so core workflows are supported. Minor gaps exist: catalog and knowledge are read-only, and there is no explicit way to list or cancel active plans.