de en es ja ko ru zh

Kronvex

Name: Kronvex
Author: Daftgoldens

by Daftgoldens

Overview Schema Related Servers Score Discussions

Python

Hybrid

Kronvex — EU-Native Memory API for AI Agents

Persistent, semantically searchable memory.
Three endpoints. GDPR-compliant. Data stays in Europe.

PyPI npm License: MIT EU Frankfurt Uptime

Why Kronvex?

Every time a user opens a new session with your AI agent, it starts from scratch. No context, no history, no user preferences. You end up injecting entire conversation histories into every prompt — expensive, slow, and context-window-limited.

Kronvex gives your agent persistent, semantically searchable memory across sessions. Store interactions, recall relevant context by meaning, inject a ready-to-use context block before each LLM call — and keep all data in Europe.

Related MCP server: Mnemoverse Memory

Performance

Endpoint	p50	p99
`/remember`	<30ms	<180ms
`/recall`	<45ms	<280ms
`/inject-context`	<55ms	<320ms

99.9% uptime · EU Frankfurt · GDPR-compliant · pgvector cosine similarity · 1536-dim embeddings

Quick Start

1. Get a free API key

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. Store a memory

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. Inject context before each LLM call

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
}

SDKs

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" }
    }
  }
}

→ Python SDK on PyPI · Node SDK on npm

How It Works

Memories are ranked by a composite confidence score:

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

Similarity: pgvector cosine similarity on 1536-dim OpenAI embeddings
Recency: sigmoid with 30-day inflection point
Frequency: log-scaled access count

Self-Hosting

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

API available at http://localhost:8000 · Docs at http://localhost:8000/docs

Endpoints

Method	Endpoint	Description
`POST`	`/auth/demo`	Get a free API key
`POST`	`/api/v1/agents`	Create an agent
`GET`	`/api/v1/agents`	List your agents
`POST`	`/api/v1/agents/{id}/remember`	Store a memory
`POST`	`/api/v1/agents/{id}/recall`	Semantic search over memories
`POST`	`/api/v1/agents/{id}/inject-context`	Get context block
`DELETE`	`/api/v1/agents/{id}/memories/{mid}`	Delete a memory
`GET`	`/health`	Health check

Full interactive docs: api.kronvex.io/docs

Pricing

Plan	Price	Agents	Memories
Free	Free	1	100
Builder	€29/mo	5	20,000
Startup	€99/mo	15	75,000
Business	€349/mo	50	500,000
Enterprise	Custom	Unlimited	Unlimited

→ See full pricing

Contributing

See CONTRIBUTING.md.

Built in Paris · 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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

memra
com.usememra
Persistent memory for AI agents. EU-hosted, privacy-first, hybrid recall, contradiction detection.
Knowledge & Memory Autonomous Agents
2
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
52
memnode
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 3 months ago (2026-06-10 13:55 UTC)
MIT
Mnemoverse Memory
Knowledge & Memory Search
mnemoverse
A
license
A
quality
A
maintenance
Persistent long-term memory for AI agents — semantic recall across Claude, Cursor, ChatGPT & MCP.
Updated 2 days ago (2026-09-03 12:12 UTC)
10
519
21
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 3 days ago (2026-09-03 00:54 UTC)
33
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 7 months ago (2026-02-11 02:32 UTC)
1
-

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/Daftgoldens/Kronvex'

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

Kronvex — EU-Native Memory API for AI Agents

Why Kronvex?

Performance

Quick Start

1. Get a free API key

2. Store a memory

3. Inject context before each LLM call

SDKs

How It Works

Self-Hosting

Endpoints

Pricing

Contributing

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

LoreConvoofficial

Latest Blog Posts

MCP directory API