Allows the Windsurf IDE (powered by Codeium) to use a PostgreSQL-backed memory and task management system, enabling persistent memory, task tracking, and dynamic database operations.
A Model Context Protocol (MCP) server that provides AI assistants with a robust "super memory", task tracker, and dynamic PostgreSQL database management capabilities.
Install the package globally:
Windows:
pip install pg-mnemosyne-mcpmacOS / Linux:
pipx install pg-mnemosyne-mcp(If you prefer standard pip or don't have pipx, run: pip install pg-mnemosyne-mcp --break-system-packages)
Auto-configure all your AI agents (Claude, Gemini, Qwen, Cursor, etc.) at once:
pg-mnemosyne init --dsn "postgresql://user:password@localhost:5432/postgres"(Be sure to replace user and password with your actual PostgreSQL username and database password!)
Restart your AI agents. You're done!
Related MCP server: FastPostgresMCP
High-Performance: Uses cached connection pooling (asyncpg.create_pool) for instant sub-millisecond database queries.
Dynamic Projects: The AI can create new databases for different projects on the fly.
Dynamic Schema: The AI can modify table schemas dynamically to adapt to changing memory needs.
Standard Memory Tracker: Built-in support for tracking, updating, and deleting memory items with tags.
Advanced Task Management: Dedicated tasks schema with fields for status transitions, priority, and deadlines.
Multi-Agent Coordination: Centralized session tracking preventing duplicate coding and file-editing conflicts.
Raw SQL Execution: Gives AI ultimate flexibility for complex queries and DDL operations.
Users will need to provide their PostgreSQL credentials using the PG_BASE_DSN environment variable. This is a standard connection string:
postgresql://<USERNAME>:<PASSWORD>@<HOST>:<PORT>/<DEFAULT_DB>
The exact location depends on which AI client you are using. You need to add the server configuration to your client's MCP settings file.
For Claude Desktop:
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
For Cursor:
Go to Settings > Features > MCP and add a new MCP server, or edit your project's .cursor/mcp.json.
For Roo Code / Cline (VS Code):
Edit the MCP settings file located at ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json (Mac) or the equivalent Windows path.
For Gemini CLI & Qwen CLI:
Open your global configuration file (usually located at ~/.gemini/settings.json or ~/.qwen/settings.json).
Alternatively, use the CLI:
gemini mcp add pg-mnemosyne "/path/to/pg-mnemosyne" -e PG_BASE_DSN="postgresql://user:pass@localhost:5432/postgres" -s user
# OR
qwen mcp add pg-mnemosyne "/path/to/pg-mnemosyne" -e PG_BASE_DSN="postgresql://user:pass@localhost:5432/postgres" -s userFor Claude Code CLI:
The easiest way is to add it via the CLI:
claude mcp add pg-mnemosyne "/path/to/pg-mnemosyne" -e PG_BASE_DSN="postgresql://user:pass@localhost:5432/postgres" -s userManually, it lives in your global config at ~/.claude.json.
For Codex CLI:
The easiest way is to add it via the CLI:
codex mcp add pg-mnemosyne --env PG_BASE_DSN="postgresql://user:pass@localhost:5432/postgres" -- pg-mnemosyneManually, it lives in your global config at ~/.codex/config.toml (TOML format).
For Windsurf IDE:
Edit your global config at ~/.codeium/windsurf/mcp_config.json.
Alternatively, click the Hammer (MCP) icon in the Cascade panel and select Configure.
For Antigravity CLI (agy): Antigravity uses a plugin-based system. To add the server:
Create a plugin directory: mkdir -p ~/.gemini/config/plugins/pg-mnemosyne
Create ~/.gemini/config/plugins/pg-mnemosyne/mcp_config.json with the Standard Template below.
Add an entry to your ~/.gemini/config/import_manifest.json under the "imports" array:
{
"name": "pg-mnemosyne",
"source": "manual",
"components": ["mcpServers"]
}Configuration Template (Claude Desktop, Cursor, Roo Code, Gemini CLI, Claude Code, Antigravity, Windsurf):
{
"mcpServers": {
"pg-mnemosyne": {
"command": "pg-mnemosyne",
"env": {
"PG_BASE_DSN": "postgresql://postgres:my_password@localhost:5432/postgres"
}
}
}
}For OpenCode:
Edit your OpenCode configuration file located at ~/.config/opencode/opencode.jsonc.
Configuration Template (OpenCode):
{
"mcp": {
"pg-mnemosyne": {
"type": "local",
"command": ["pg-mnemosyne"],
"environment": {
"PG_BASE_DSN": "postgresql://postgres:my_password@localhost:5432/postgres"
}
}
}
}pg-mnemosyne runThis starts the MCP server using standard input/output.
The pg-mnemosyne command also acts as a standalone CLI for managing your data and configuring agents.
You can automatically configure all supported AI agents (Claude, Gemini, Qwen, Cursor, etc.) with a single command:
pg-mnemosyne init --dsn "postgresql://user:pass@localhost:5432/postgres"You can add and list records directly from your terminal:
# Add a record
pg-mnemosyne add my_project_db todo "Finish the documentation"
# List records
pg-mnemosyne list my_project_db --type todoPg-Mnemosyne includes specialized schemas to help complex multi-agent setups (e.g. Gemini CLI, Codex CLI, Roo Code, Claude Desktop) coordinate on the same project:
Spin up a dedicated tasks table with fields for statuses (backlog, todo, in_progress, blocked, done), priority levels (low, medium, high, critical), tags, and deadlines:
pg-mnemosyne init-todo my_project_dbAvoid merge conflicts, double-coding, and redundant compiler troubleshooting by initializing the shared agent_sessions coordination table:
pg-mnemosyne init-coordination my_project_dbWhen active, agents use the update_agent_session and get_active_sessions MCP tools to register their current editing files and active subtasks, creating a real-time bulletin board for mutual visibility!
create_project_db(db_name: str): Creates a new isolated PostgreSQL database.
init_schema(db_name: str): Initializes the base records table.
init_todo_schema(db_name: str): Initializes a professional tasks table.
init_coordination_schema(db_name: str): Initializes the multi-agent agent_sessions table.
add_column(db_name: str, table: str, column_name: str, data_type: str): Dynamically adds a column to any table.
add_record(db_name: str, type: str, content: str, tags: list[str]): Adds a memory/todo record.
get_records(db_name: str, type: str = None, limit: int = 50): Retrieves recent records.
update_record(db_name: str, record_id: int, content: str = None, tags: list[str] = None, status: str = None): Partially updates a record.
delete_record(db_name: str, record_id: int): Deletes a record by ID.
update_agent_session(db_name: str, agent_name: str, active_task: str, active_file: str = None, status: str = "active"): Registers/updates active agent state.
get_active_sessions(db_name: str): Lists active agent coordination sessions.
run_sql(db_name: str, query: str): Runs arbitrary SQL (SELECT, INSERT, DDL, etc.).
Adds a new column to a table dynamically.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes | ||
| table | Yes | ||
| column_name | Yes | ||
| data_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. The term 'dynamically hints at schema modification, but there is no explanation of side effects (e.g., locking, irreversibility, permission requirements) or return behavior. The output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and concise, fitting the tool's simplicity. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 4 required parameters, and an output schema, the description lacks completeness. It does not mention that the target table must exist, what happens on success/failure, or reference the output schema. Critical context for a schema-altering operation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning beyond field names. It does not. For example, 'data_type' could be clarified with acceptable values (e.g., 'TEXT', 'INTEGER'). The description only restates the tool's action, providing no parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Adds a new column to a table dynamically' clearly specifies the verb (adds) and resource (new column to a table). It implicitly distinguishes from sibling tools like 'add_record' (adds a record) and 'run_sql' (generic SQL). The word 'dynamically' adds context, making the purpose very specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided about when to use this tool versus alternatives. For instance, it does not mention prerequisites (e.g., table must exist), nor does it contrast with similar tools like 'run_sql' for schema changes. The description offers no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds a new memory/task record.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes | ||
| type | Yes | ||
| content | Yes | ||
| tags | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only says 'Adds', implying creation, but does not disclose whether the operation is idempotent, what side effects occur, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one phrase), but it sacrifices informativeness. While not verbose, it fails to provide necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema that may describe return values, the description lacks information about parameter usage, prerequisites, and behavioral details, making it incomplete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (db_name, type, content, tags). The user must infer their meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Adds a new memory/task record' clearly states the action (adds) and the resource (memory/task record), distinguishing it from sibling tools like 'delete_record' or 'update_record'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'update_record' or when not to use it. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new PostgreSQL database for a project.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose side effects (e.g., idempotency), naming constraints, permissions needed, or the output format. Only basic create action is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with verb and resource. No wasted words, but missing important details. Conciseness is good but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param), the description is minimally acceptable. However, lack of behavioral info and output schema reference makes it incomplete for an agent to use without assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It says db_name is for a project but does not clarify validation rules, allowed characters, or maximum length. The parameter meaning is only partially conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'creates', the resource 'PostgreSQL database', and the target 'for a project'. It distinguishes from sibling tools like add_column, add_record, etc., which operate on existing databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, naming conventions, or error handling (e.g., if database already exists). Sibling tools like init_schema might be used after, but no sequence is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a record from the database by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes | ||
| record_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose consequences such as irreversibility, cascade effects, or required permissions. A destructive action needs more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and very short. While not verbose, it is underspecified for the required information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no schema descriptions, the description is too sparse. It should explain both parameters and the effects of deletion, especially since no output schema is present to clarify behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions record_id. The db_name parameter is left unexplained, so the description adds minimal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deletes), the resource (record), and the method (by ID). It effectively distinguishes from sibling tools like add_record and update_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or postconditions. The description does not help the agent decide whether deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all registered agent coordination sessions ordered by last active time.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions retrieval and ordering, but does not disclose whether it requires authentication, whether it changes state, or what the response format is. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but sacrifices necessary detail. It could be expanded to include parameter guidance or behavioral notes while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a database retrieval tool with one required parameter and no output schema details in the description, the description is incomplete. It does not explain what a coordination session is or how to use the db_name parameter. Lacks context for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter db_name has 0% schema description coverage, and the description does not explain its purpose or expected values. The agent has no information about what db_name refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Retrieves) and the resource (all registered agent coordination sessions) with an ordering clause. It is specific and distinguishes from sibling tools like update_agent_session or add_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no context about typical use cases or exclusions. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves recent records from the database.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes | ||
| type | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'retrieves recent records'. It does not explain what 'recent' means, side effects, or read-only nature, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. However, it is too brief to be fully helpful; conciseness is maintained but sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters and no schema descriptions, the description is incomplete. It lacks context on what records are retrieved, how 'recent' is defined, or how limit and type affect results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It fails to mention db_name, type, or limit—adding no meaning beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieves) and resource (recent records from database). It distinguishes from sibling tools like add_record and delete_record, though it could be more specific about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when or when not to use this tool, nor any alternatives mentioned. The description simply states what it does without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initializes the 'agent_sessions' table for multi-agent coordination.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the initialization is destructive (drops existing table), handles idempotency, or requires specific permissions. The behavior beyond table creation is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It uses only 8 words, missing critical information that could be added without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of schema initialization (potential destructive action, need for prerequisites) and the presence of sibling tools for other schemas, the description is incomplete. It does not explain the relationship to init_schema or the expected return value, despite an output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage; the parameter 'db_name' has no explanation in schema or description. The description does not clarify what 'db_name' refers to (e.g., database name, file path, connection name), leaving the agent to guess its semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool initializes the 'agent_sessions' table for multi-agent coordination. It specifies the resource (table name) and context, distinguishing it from siblings like init_schema and init_todo_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., the database must already exist) or when it should not be used. Sibling tools like init_schema suggest alternative schemas, but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initializes the base 'records' table in the specified database.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It does not state whether the operation is safe to repeat, what happens if the table already exists, or any required permissions. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise, but it lacks crucial details. While it is not verbose, the conciseness comes at the cost of completeness, making it borderline underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description could be more complete by mentioning return values or side effects. It fails to cover key aspects like idempotency or expected behavior on repeated calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description provides no additional meaning for the 'db_name' parameter. It fails to explain what the parameter represents (e.g., database name or path), making it insufficient for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it initializes the base 'records' table, specifying the verb and resource. However, it does not explicitly differentiate from sibling tools like init_coordination_schema or init_todo_schema, though the tool name provides some context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 its siblings (e.g., init_coordination_schema) or when not to use it (e.g., if the table already exists). The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initializes a professional 'tasks' table in the specified database.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals no behavioral details beyond the bare action. Key traits like destructiveness (e.g., overwriting existing table), required permissions, or side effects are omitted. Since no annotations exist, the description should cover these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but critically lacking in useful information. It fails to include essential details, making it under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and an output schema, the description omits any mention of return values, error conditions, or the specific structure of the 'tasks' table. For a tool that initializes a database artifact, this is insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the parameter 'db_name' has no description in the schema. The tool description does not explain what 'db_name' represents (database name, schema name, or something else), leaving the agent uninformed about how to properly set this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initializes a 'tasks' table in a database, specifying the resource and action. However, the term 'professional' is vague and it doesn't differentiate from sibling tools like init_schema or init_coordination_schema, which may have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as init_schema or create_project_db. There is no mention of prerequisites, nor scenarios where this tool should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes arbitrary SQL queries and returns results as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to disclose potential destructive actions, required permissions, error handling, or result limits, which are critical for arbitrary SQL execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise. However, it is too brief and lacks information that could be included without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits details about query restrictions, timeout, result size, or side effects. Incomplete for the complexity of arbitrary SQL execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or format of db_name or query parameters beyond their names. No added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool executes SQL queries and returns JSON results. However, it does not distinguish from sibling tools like add_record or delete_record, which also operate on databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. siblings like add_record or delete_record. The description is too generic to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates or registers the active task and state of an agent in the database (thread-safe upsert).
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes | ||
| agent_name | Yes | ||
| active_task | Yes | ||
| active_file | No | ||
| status | No | active |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context with 'thread-safe upsert', which is beyond the schema's domain. It implies atomicity and concurrency safety, but does not detail side effects like complete overwrite of existing state or necessary permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and a key behavioral trait (thread-safe upsert) without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no schema descriptions, no annotations), the description is too minimal. It omits details on parameter effects, return values (despite an output schema existing), and the overall impact of the upsert operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain individual parameters. It mentions 'active task' and vaguely references 'state', but fails to clarify the roles of db_name, agent_name, active_file, or status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'updates or registers' and the resource 'active task and state of an agent in the database', making it distinct from sibling tools like update_record which is more generic. It explicitly uses 'upsert' to indicate combined insert/update behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description lacks conditions, prerequisites, or scenarios where this tool is preferred over siblings like update_record or add_record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates a record in the database by its ID. Only non-None fields will be updated.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes | ||
| record_id | Yes | ||
| content | No | ||
| tags | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states that only non-None fields are updated, which is important behavioral context. However, it does not disclose behavior on missing record ID, side effects, or return value expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. While it efficiently states the action and partial update behavior, it omits essential information, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 5 parameters (2 required) and no parameter descriptions, the description is insufficient. It fails to provide context about which database, record existence, or how it compares to sibling tools like add_record or run_sql.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-specific meaning beyond what the schema provides. It mentions 'by its ID' but does not explain db_name, content, tags, or status fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Updates' and the resource 'a record in the database by its ID', making the primary action unambiguous. It distinguishes from sibling tools like add_record and delete_record by specifying the update action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as add_record or run_sql. The description does not specify prerequisites, context for use, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: schema initialization, CRUD for records, session management, and utility operations. There is no functional overlap between tools.
All tools follow a consistent verb_noun pattern using underscores, e.g., add_column, get_records, update_agent_session. The convention is uniform.
With 12 tools, the surface is well-scoped for database management, covering setup, CRUD, session tracking, and utilities without being over- or under-engineered.
Core record CRUD and session management are present, but there are no specific tools for task CRUD (only init_todo_schema) and no schema deletion or modification beyond add_column. Gaps require use of run_sql.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
An agent-native database over MCP: shared, validated, structured records in every AI chat.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Janadasroor/pg-mnemosyne-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
