de en es ja ko ru zh

Kronvex

Name: Kronvex
Author: Daftgoldens

by Daftgoldens

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Kronvex — 面向 AI 智能体的欧盟原生内存 API

持久化、语义可搜索的内存。三个端点。符合 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% 正常运行时间 · 欧盟法兰克福 · 符合 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 天拐点的 S 型函数
频率: 对数缩放的访问计数

自托管

# 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

定价

计划	价格	智能体	记忆
免费	免费	1	100
开发者	€29/月	5	20,000
初创企业	€99/月	15	75,000
商业版	€349/月	50	500,000
企业版	定制	无限	无限

→ 查看完整定价

贡献

请参阅 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 3 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 — 面向 AI 智能体的欧盟原生内存 API

为什么选择 Kronvex？

性能

快速入门

1. 获取免费 API 密钥

2. 存储记忆

3. 在每次 LLM 调用前注入上下文

SDK

工作原理

自托管

端点

定价

贡献

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

LoreConvoofficial