de en es ja ko ru zh

Kronvex

Name: Kronvex
Author: Daftgoldens

by Daftgoldens

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Kronvex — EU 기반 AI 에이전트용 메모리 API

영구적이고 의미론적으로 검색 가능한 메모리. 3개의 엔드포인트. GDPR 준수. 데이터는 유럽 내에 보관됩니다.

PyPI npm License: MIT EU Frankfurt Uptime

왜 Kronvex인가?

사용자가 AI 에이전트와 새로운 세션을 시작할 때마다 에이전트는 처음부터 다시 시작합니다. 컨텍스트도, 기록도, 사용자 선호도도 없습니다. 결국 모든 프롬프트에 전체 대화 기록을 주입하게 되는데, 이는 비용이 많이 들고 느리며 컨텍스트 윈도우 제한에 걸리게 됩니다.

Kronvex는 에이전트에게 세션 전반에 걸쳐 영구적이고 의미론적으로 검색 가능한 메모리를 제공합니다. 상호작용을 저장하고, 의미에 따라 관련 컨텍스트를 호출하며, 각 LLM 호출 전에 즉시 사용 가능한 컨텍스트 블록을 주입하세요. 모든 데이터는 유럽 내에 안전하게 보관됩니다.

Related MCP server: Mnemoverse Memory

성능

엔드포인트	p50	p99
`/remember`	<30ms	<180ms
`/recall`	<45ms	<280ms
`/inject-context`	<55ms	<320ms

99.9% 가동 시간 · EU 프랑크푸르트 · GDPR 준수 · pgvector 코사인 유사도 · 1536차원 임베딩

빠른 시작

1. 무료 API 키 받기

curl -X POST https://api.kronvex.io/auth/demo \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Alice",
    "email": "alice@company.com",
    "usecase": "Customer support bot with memory"
  }'

{
  "full_key": "kv-xxxxxxxxxxxxxxxx",
  "agent_id": "uuid-of-your-first-agent",
  "memory_limit": 100,
  "message": "Ready! Your API key and first agent are set up."
}

2. 메모리 저장하기

curl -X POST https://api.kronvex.io/api/v1/agents/{agent_id}/remember \
  -H "X-API-Key: kv-xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"content": "Alice is a Premium customer since January 2023."}'

3. 각 LLM 호출 전에 컨텍스트 주입하기

curl -X POST https://api.kronvex.io/api/v1/agents/{agent_id}/inject-context \
  -H "X-API-Key: kv-xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"message": "I still have that billing issue"}'

{
  "context_block": "[KRONVEX CONTEXT]\n- Alice is a Premium customer since Jan 2023 (similarity: 0.94)",
  "memories_used": 1
}

SDK

Python

pip install kronvex

from kronvex import Kronvex

kx = Kronvex("kv-your-api-key")
agent = kx.agent("your-agent-id")

await agent.remember("User prefers concise answers")
context = await agent.inject_context("How should I format this?")

Node.js / TypeScript

npm install kronvex

import { Kronvex } from "kronvex";

const kx = new Kronvex("kv-your-api-key");
const agent = kx.agent("your-agent-id");

await agent.remember("User prefers concise answers");
const context = await agent.injectContext("How should I format this?");

MCP (Claude Desktop)

{
  "mcpServers": {
    "kronvex": {
      "command": "npx",
      "args": ["kronvex-mcp"],
      "env": { "KRONVEX_API_KEY": "kv-your-api-key" }
    }
  }
}

→ PyPI의 Python SDK · npm의 Node SDK

작동 원리

메모리는 복합 신뢰도 점수에 따라 순위가 매겨집니다:

confidence = similarity × 0.6 + recency × 0.2 + frequency × 0.2

유사도: 1536차원 OpenAI 임베딩에 대한 pgvector 코사인 유사도
최신성: 30일 변곡점을 가진 시그모이드 함수
빈도: 로그 스케일의 액세스 횟수

자체 호스팅

# Requires Docker
cp .env.example .env
# Edit .env with your OPENAI_API_KEY and DATABASE_URL
docker-compose up --build

API는 http://localhost:8000에서 사용 가능 · 문서: http://localhost:8000/docs

엔드포인트

메서드	엔드포인트	설명
`POST`	`/auth/demo`	무료 API 키 받기
`POST`	`/api/v1/agents`	에이전트 생성
`GET`	`/api/v1/agents`	에이전트 목록 조회
`POST`	`/api/v1/agents/{id}/remember`	메모리 저장
`POST`	`/api/v1/agents/{id}/recall`	메모리 의미론적 검색
`POST`	`/api/v1/agents/{id}/inject-context`	컨텍스트 블록 가져오기
`DELETE`	`/api/v1/agents/{id}/memories/{mid}`	메모리 삭제
`GET`	`/health`	상태 확인

전체 대화형 문서: api.kronvex.io/docs

요금제

플랜	가격	에이전트	메모리
Free	무료	1	100
Builder	€29/월	5	20,000
Startup	€99/월	15	75,000
Business	€349/월	50	500,000
Enterprise	맞춤형	무제한	무제한

→ 전체 요금제 보기

기여하기

CONTRIBUTING.md를 참조하세요.

파리에서 제작됨 · kronvex.io · hello@kronvex.io

Available Tools

4 tools

forgetA

Search for memories matching a query and permanently delete the top matches. Use this to remove outdated, incorrect, or superseded information from memory.

When to call: when the user explicitly asks to forget something, or when you detect that a stored memory is no longer accurate (e.g. a dependency was upgraded, a decision was reversed, a team member left).

Internally performs a high-threshold semantic search (0.7) to find close matches, then deletes up to 3 results. Returns a list of deleted memories or a message if nothing matched.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Describe what should be forgotten in plain language. The search is semantic — describe the topic or fact, not exact wording. Example: 'old database URL', 'previous deployment process', 'user preference for Python 3.9'. Only memories with high similarity (≥0.7) are deleted.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so well. It discloses key behavioral traits: performs a high-threshold semantic search (0.7), deletes up to 3 results, and returns a list of deleted memories or a message if nothing matched. It also clarifies the permanent nature of deletion ('permanently delete'). However, it doesn't mention potential side effects like error handling or confirmation prompts.

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 well-structured and appropriately sized. It front-loads the core purpose, then provides usage guidelines, and finally details internal behavior. Every sentence adds value, though it could be slightly more concise by integrating some details (e.g., the 0.7 threshold is mentioned twice).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive operation with semantic search), no annotations, and no output schema, the description is quite complete. It covers purpose, usage, behavior, and parameter context. However, it lacks details on error cases, authentication needs, or rate limits, which would be helpful for a destructive tool.

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% for the single parameter 'query', so the baseline is 3. The description adds some context by reinforcing the semantic search aspect and giving examples ('old database URL', etc.), but doesn't provide significant additional meaning beyond what's already in the schema description (which already explains semantic search and gives examples).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('search for memories' and 'permanently delete the top matches') and distinguishes it from siblings (recall, remember, inject_context) by emphasizing deletion rather than retrieval or storage. It explicitly mentions what resource it operates on (memories).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'when the user explicitly asks to forget something' or 'when you detect that a stored memory is no longer accurate.' It gives concrete examples (e.g., dependency upgraded, decision reversed, team member left), clearly differentiating it from recall/remember tools which are for retrieval/storage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inject_contextA

Retrieve the most relevant memories for the current task and return them as a single formatted context block, ready to prepend to a prompt or include in a system message.

When to call: at the start of a complex or multi-step task where relevant project history, constraints, or preferences may exist in memory. Prefer this over recall when you want a single ready-to-use block rather than a list of individual memories.

Returns a formatted text block summarising the relevant memories, and a count of how many memories were used. Returns empty if none are relevant.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Describe the current task or topic in plain language. The server retrieves memories semantically related to this description. Example: 'refactoring the authentication module' or 'setting up the CI pipeline for the mobile app'.

TDQS

A4.6/5.0

Behavior4/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 effectively describes what the tool does (retrieves relevant memories, formats them into a block, returns count), what happens when no memories are relevant (returns empty), and the output format. However, it doesn't mention potential limitations like rate limits, memory constraints, or semantic matching accuracy.

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 well-structured and front-loaded with the core purpose, followed by usage guidelines and return behavior. Every sentence adds value without redundancy, and the three paragraphs efficiently cover purpose, usage, and output without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description does an excellent job covering the essential aspects: purpose, usage context, parameter semantics, and return behavior. However, it doesn't detail the exact format of the 'formatted text block' or potential error conditions, leaving some ambiguity about the output structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents the single 'query' parameter. The description adds value by explaining the semantic nature of the retrieval ('retrieves memories semantically related to this description') and providing context about how the query should be formulated ('Describe the current task or topic in plain language'), which goes beyond the schema's technical specification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('retrieve', 'return') and resources ('memories'), distinguishing it from siblings by specifying it returns a 'single formatted context block' rather than individual memories. It explicitly contrasts with the 'recall' sibling tool, providing clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('at the start of a complex or multi-step task') and when not to use it ('Prefer this over recall when you want a single ready-to-use block rather than a list of individual memories'). It names the alternative tool ('recall') and specifies the context where this tool is preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recallA

Search long-term memory using semantic similarity and return the most relevant stored memories ranked by a confidence score (weighted combination of similarity, recency, and access frequency).

When to call: before starting a task, when the user references something from a past session, or when you need project-specific context.

Returns a ranked list of memories with their confidence score and type. Returns an empty result if no memories exceed the similarity threshold.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Natural language description of what you are looking for. The search is semantic, not keyword-based — describe the concept, not the exact wording. Example: 'database connection settings' or 'user preferences for code style'.
`top_k`	No	Maximum number of memories to return, ranked by confidence. Use 3–5 for focused lookups, up to 10 for broad exploration. Defaults to 5.

TDQS

A4.4/5.0

Behavior4/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 explains key behavioral traits: the search is semantic (not keyword-based), returns ranked results with confidence scores, and returns empty results if no memories exceed the similarity threshold. It doesn't mention rate limits, authentication needs, or error conditions, but covers the core operational behavior well.

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 efficiently structured with three focused paragraphs: purpose, usage guidelines, and return behavior. Each sentence adds distinct value - no repetition or wasted words. The information is front-loaded with the core functionality stated first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description provides good coverage of what the tool does, when to use it, and what it returns. It explains the confidence scoring mechanism and empty result behavior. It could benefit from mentioning the memory types available or error conditions, but overall provides sufficient 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 already fully documents both parameters. The description adds minimal value beyond the schema - it mentions 'semantic similarity' which relates to the query parameter, but doesn't provide additional parameter semantics. The baseline of 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('search long-term memory', 'return the most relevant stored memories') and distinguishes it from siblings by mentioning semantic similarity and confidence scoring. It explicitly identifies what makes this tool unique compared to tools like 'forget', 'inject_context', and 'remember'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'before starting a task, when the user references something from a past session, or when you need project-specific context.' This gives clear situational triggers and distinguishes it from alternative memory-related tools without being misleading.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rememberA

Persist a piece of information to long-term memory so it can be recalled in future sessions. Use this whenever the user states a preference, makes a decision, or shares context that should survive beyond the current conversation.

When to call: after learning the user's tech stack, coding conventions, project constraints, architectural decisions, or personal preferences.

Returns a confirmation message with the stored content preview.

Examples of good memories:

'User prefers TypeScript strict mode with no implicit any'
'Database: PostgreSQL 16 with pgvector on Railway, connection via asyncpg'
'Never use any() type in this codebase — team policy'
'Deployed on 2024-03-15: migrated auth from JWT to Supabase sessions'

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	The information to store. Write in a self-contained, specific way so it remains useful without conversation context. Good: 'API rate limit is 100 req/min per key'. Bad: 'the limit we discussed'.
`memory_type`	No	Category of the memory: - episodic: a specific past event or decision (e.g. 'Deployed v2 on 2024-03-10') - semantic: a general fact, preference, or project truth (e.g. 'User prefers tabs over spaces') - procedural: a how-to, pattern, or repeatable process (e.g. 'To deploy: run npm run build then railway up') Defaults to 'semantic' when unsure.	semantic

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It effectively describes key behaviors: the tool persists information across sessions, returns a confirmation message with preview, and provides concrete examples of appropriate content. However, it doesn't mention potential limitations like storage capacity, retention policies, or error conditions that might be relevant for a memory 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 well-structured and front-loaded with the core purpose in the first sentence. Each subsequent section (when to call, return value, examples) adds specific value without redundancy. The examples are concrete and illustrative, earning their place by clarifying appropriate usage. No sentence is wasted or repetitive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters, 100% schema coverage, and no output schema, the description provides strong contextual completeness. It covers purpose, usage guidelines, behavioral expectations, and practical examples. The main gap is the lack of output schema, but the description compensates by explicitly stating what the tool returns ('confirmation message with stored content preview'). A perfect score would require more detail about potential edge cases or limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by providing concrete examples of good memory content ('User prefers TypeScript strict mode...') and explaining the practical application of memory types through usage examples. This helps the agent understand how to format content appropriately, though it doesn't provide additional technical details about parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('persist', 'recalled') and resource ('piece of information to long-term memory'). It distinguishes from sibling tools by focusing on storage rather than retrieval (recall), removal (forget), or injection (inject_context). The first sentence provides a complete, unambiguous statement of function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'whenever the user states a preference, makes a decision, or shares context that should survive beyond the current conversation.' It offers specific examples of appropriate contexts (tech stack, coding conventions, project constraints, etc.) and distinguishes from alternatives by focusing on persistence for future sessions rather than immediate recall or context injection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.1Apr 13, 2026

Changedforget1 field changed

changedInput schema / properties / query / description

Previous value: -"What to forget. Searches semantically, then deletes matches."New value: +"Describe what should be forgotten in plain language. The search is semantic — describe the topic or fact, not exact wording. Example: 'old database URL', 'previous deployment process', 'user preference for Python 3.9'. Only memories with high similarity (≥0.7) are deleted."

Changedinject_context1 field changed

changedInput schema / properties / query / description

Previous value: -"The current task or topic to retrieve context for."New value: +"Describe the current task or topic in plain language. The server retrieves memories semantically related to this description. Example: 'refactoring the authentication module' or 'setting up the CI pipeline for the mobile app'."

Changedrecall2 fields changed

changedInput schema / properties / query / description

Previous value: -"What to search for. Use natural language."New value: +"Natural language description of what you are looking for. The search is semantic, not keyword-based — describe the concept, not the exact wording. Example: 'database connection settings' or 'user preferences for code style'."

changedInput schema / properties / top_k / description

Previous value: -"Number of results to return (1-10)"New value: +"Maximum number of memories to return, ranked by confidence. Use 3–5 for focused lookups, up to 10 for broad exploration. Defaults to 5."

Changedremember2 fields changed

changedInput schema / properties / content / description

Previous value: -"The information to remember. Be specific and complete."New value: +"The information to store. Write in a self-contained, specific way so it remains useful without conversation context. Good: 'API rate limit is 100 req/min per key'. Bad: 'the limit we discussed'."

changedInput schema / properties / memory_type / description

Previous value: -"episodic = specific events/decisions, semantic = general facts/preferences, procedural = how-to knowledge/patterns"New value: +"Category of the memory:\n- episodic: a specific past event or decision (e.g. 'Deployed v2 on 2024-03-10')\n- semantic: a general fact, preference, or project truth (e.g. 'User prefers tabs over spaces')\n- procedural: a how-to, pattern, or repeatable process (e.g. 'To deploy: run npm run build then railway up')\nDefaults to 'semantic' when unsure."

4 tool updatesv1.0.0Apr 13, 2026
- First observedforget
- First observedinject_context
- First observedrecall
- First observedremember

Deploy Server

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A4.5/5.0

Scored 2026-04-13 22:05 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: forget deletes memories, inject_context formats them for immediate use, recall retrieves them as a ranked list, and remember stores new memories. The descriptions explicitly differentiate their roles, making misselection unlikely.

Naming Consistency5/5

All tool names follow a consistent verb-based pattern (forget, inject_context, recall, remember) that directly reflects their core actions. The naming is uniform and predictable, with no deviations in style or convention.

Tool Count5/5

With 4 tools, this server is well-scoped for its memory management domain, covering the essential CRUD-like operations (create, read, delete) plus a specialized formatting tool. Each tool earns its place without feeling excessive or insufficient.

Completeness4/5

The toolset provides strong coverage for memory operations: remember (create), recall (read), forget (delete), and inject_context (format). A minor gap exists in update functionality for modifying existing memories, but agents can work around this by deleting and re-adding.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

memra A
com.usememra
Persistent memory for AI agents. EU-hosted, privacy-first, hybrid recall, contradiction detection.
Knowledge & Memory Autonomous Agents
72
mifactory-agent-memory C
io.github.mifactory-bot
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
22
stagenth · AI 记忆库 A
com.stagenth
Hosted persistent memory with semantic search, importance and TTL for AI agents.
Knowledge & Memory RAG Systems
2
memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2

Related MCP Servers

MemoryAPI
Knowledge & Memory RAG Systems Vector Databases
heavysword1
A
license
Not graded
quality
D
maintenance
Persistent memory for AI agents. Store and semantically search memories via REST API or MCP. Free tier available.
Updated 4 months ago (2026-06-10 13:55 UTC)
MIT
Mnemoverse Memory
Autonomous Agents Knowledge & Memory Search
mnemoverse
A
license
A
quality
A
maintenance
Hosted memory for AI agents that learns from outcomes, with shared rooms. One key across Claude, Cursor & ChatGPT.
Updated 2 days ago (2026-10-11 15:25 UTC)
6
11
297 npm
26
MIT
LoreConvoofficial
Knowledge & Memory Search
labyrinth-analytics
A
license
A
quality
A
maintenance
Persistent memory layer for MCP-compatible AI agents. Implements save/recall/search over a local SQLite session store via 14 MCP tools. Auto-loads relevant context at session start. No cloud dependency. Works with Claude, Cursor, Codex, Hermes Agent. Free (50 sessions) / Pro ($8/mo).
Updated 6 days ago (2026-10-07 20:51 UTC)
33
443 PyPI
10
Business Source 1.1
MCP Memory
Knowledge & Memory Search
TWFBusiness
F
license
Not graded
quality
D
maintenance
Persistent memory server for AI assistants with semantic search and three-layer context (global, project, personality). Works with MCP-compatible AI tools like Claude Code, Cursor, Continue, Cline, and more.
Updated 8 months ago (2026-02-11 02:32 UTC)
1
-

Kronvex — EU 기반 AI 에이전트용 메모리 API

왜 Kronvex인가?

성능

빠른 시작

1. 무료 API 키 받기

2. 메모리 저장하기

3. 각 LLM 호출 전에 컨텍스트 주입하기

SDK

작동 원리

자체 호스팅

엔드포인트

요금제

기여하기

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

LoreConvoofficial