lorecards-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LORECARDS_VAULT | No | Path to the card vault directory. If not set, defaults to ~/.lorecards. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_cardsA | List every card in the book, optionally of one kind (people, event, place, thing, slang, entry). |
| read_cardA | Read one whole card by key (its file name without .md). |
| write_cardA | Write a card. kind: people | event | place | thing | slang | entry. key: the card's file name, also its default title. fields: section name -> text. people: who/stance/recent/impression; event: when/who/what/stance/followup; place: where/relation/recent; thing: what/usage/recent; slang: meaning/origin/usage; entry: {"_head": "..."}. keywords: what the card listens for. aliases: other ways the subject gets named. refs: keys of other cards worth one line of context when this one fires. mode="create" refuses to overwrite an existing card; mode="update_recent" rewrites only the recent section (followup for events) of a card that already exists. |
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 3 tools
list_cards, read_card, and write_card map cleanly onto list/read/write with no overlap. The only internal branching is write_card's mode parameter (create vs update_recent), which is explicitly documented rather than a separate ambiguous tool.
All three names follow a strict verb_noun snake_case pattern (list_cards, read_card, write_card). The verbs are distinct and predictable, with no mixed conventions or casing anomalies.
Three tools is lean but defensible for a card store, since write_card's mode parameter absorbs both creation and partial updates. It sits at the lower edge of comfortable scope, with no obvious redundancy.
The surface covers list/read/write but has no delete or remove operation, leaving cards unremovable once written. There is also no search-by-keyword tool, even though keywords and aliases are first-class fields, forcing agents to list everything and filter client-side.