Pensieve MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: append_to_conversation modifies content, list_conversations retrieves metadata, load_conversation accesses full conversations, save_conversation persists them, and search_conversations finds specific content. There is no overlap in functionality that would cause confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case (e.g., append_to_conversation, list_conversations). The verbs (append, list, load, save, search) are distinct and appropriately descriptive, making the set predictable and easy to understand.
Tool Count5/5
With 5 tools, this server is well-scoped for managing conversations, covering essential operations like listing, loading, saving, appending, and searching. Each tool earns its place without feeling excessive or insufficient for the domain.
Completeness4/5
The tool set provides strong coverage for core conversation management tasks, including CRUD-like operations (create via append/save, read via list/load/search). A minor gap is the lack of explicit delete or update tools, but agents can work around this by overwriting or managing storage externally.
Average 2.6/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but reveals minimal behavior. It implies a write operation ('저장합니다' - saves) but doesn't disclose permissions needed, whether it's idempotent, error conditions, or side effects. It mentions auto-generation of conversation_id if missing, which is useful, but lacks details on storage format, persistence, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately brief given the tool's straightforward name, though this conciseness comes at the cost of detail. Every word earns its place in conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, nested objects, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, return values, or how it interacts with sibling tools. The auto-generation hint for conversation_id is helpful but doesn't compensate for missing behavioral and contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no parameter-specific information beyond the schema's details for conversation_id, messages, and metadata. Baseline score of 3 applies as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '대화 내역을 저장합니다' (Saves conversation history) states the basic action but is vague about scope and mechanism. It doesn't specify whether this creates new conversations or updates existing ones, nor does it differentiate from sibling tools like 'append_to_conversation' or 'load_conversation'. The description essentially restates the tool name without adding meaningful specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, when to choose 'save_conversation' over 'append_to_conversation' for updates, or how it relates to 'list_conversations' or 'search_conversations'. The description offers no context for decision-making among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While '조회합니다' (retrieve/list) implies a read-only operation, the description doesn't mention pagination behavior (implied by limit/offset parameters), rate limits, authentication requirements, or what constitutes 'stored' conversations. This leaves significant gaps for a tool that presumably accesses user data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. However, it could be slightly more front-loaded with key distinguishing information given the sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned (conversation titles, dates, IDs?), the format of results, error conditions, or how 'stored conversations' are defined. The agent lacks crucial context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear documentation of both parameters (limit and offset with defaults). The tool description adds no parameter information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('조회합니다' - retrieve/list) and resource ('저장된 대화 목록' - stored conversation list), which gives a basic understanding of the tool's function. However, it doesn't distinguish this tool from sibling tools like 'search_conversations' or clarify what 'stored conversations' means versus other conversation types that might exist in the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_conversations' or 'load_conversation'. There's no mention of prerequisites, typical use cases, or exclusion criteria. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('불러옵니다' - loads) but doesn't clarify if this is a read-only operation, what permissions are required, how errors are handled (e.g., invalid ID), or the return format. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('저장된 대화를 불러옵니다') that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with additional context if needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with one parameter) and the absence of annotations and output schema, the description is incomplete. It doesn't explain what '불러옵니다' entails (e.g., returns conversation data, metadata, or both), error conditions, or how it fits with siblings, making it inadequate for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'conversation_id' clearly documented as '불러올 대화 ID' (ID of the conversation to load). The description doesn't add any meaning beyond this, such as format examples or sourcing hints. According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '저장된 대화를 불러옵니다' (Loads a saved conversation) clearly states the verb ('불러옵니다' - loads) and resource ('저장된 대화' - saved conversation), making the basic purpose understandable. However, it doesn't differentiate from siblings like 'search_conversations' or 'list_conversations' in terms of scope or function, leaving the distinction ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a conversation_id from 'list_conversations'), exclusions, or comparisons to siblings like 'search_conversations' for filtering or 'append_to_conversation' for updates, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action (search) without mentioning permissions, rate limits, response format, pagination, or whether it's read-only. For a search tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean with zero waste. However, it's under-specified rather than concise—it lacks necessary details, so while it's structurally simple, it doesn't fully earn its place by providing adequate information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search operation, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how results are structured, or any behavioral aspects. For a tool with two parameters and no structured support, this minimal description fails to provide enough context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters (query and limit). The description adds no additional meaning beyond what the schema provides, such as query syntax examples or limit constraints. Baseline 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '대화 내용을 검색합니다' (Search conversation content) states a clear verb (search) and resource (conversation content), but it's vague about scope and doesn't distinguish from sibling tools like 'list_conversations'. It doesn't specify what kind of conversations or what 'content' includes beyond the basic purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_conversations' or 'load_conversation'. The description implies searching within content, but it doesn't specify use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action (append) but doesn't cover permissions, side effects, response format, or error handling. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's purpose, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, outcomes, and integration with sibling tools, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters (conversation_id and messages). The description adds no additional meaning beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '기존 대화에 메시지를 추가합니다' (Appends messages to an existing conversation) clearly states the action (append) and resource (conversation), but it's vague about scope and doesn't distinguish from siblings like 'save_conversation'. It's functional but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'save_conversation' or 'load_conversation'. The description implies usage for adding messages but offers no context on prerequisites, exclusions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pensieve-mcp MCP server](https://glama.ai/mcp/servers/EmjayAhn/pensieve-mcp/badges/card.svg)](https://glama.ai/mcp/servers/EmjayAhn/pensieve-mcp)

Score Badge

Copy to your README.md:

[![pensieve-mcp MCP server](https://glama.ai/mcp/servers/EmjayAhn/pensieve-mcp/badges/score.svg)](https://glama.ai/mcp/servers/EmjayAhn/pensieve-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EmjayAhn/pensieve-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server