Memory Journal MCP Server

Create Team Entry

team_create_entry

Create a structured markdown entry in the team database to share project insights and session summaries with collaborators, ensuring proper categorization and context linking.

Instructions

Create an entry in the team database for sharing with collaborators. ONLY use when explicitly requested by the user. Default to personal create_entry instead. Content must be well-structured markdown using ## section headers. Select the most accurate entry_type (e.g., retrospective, technical_note). For session summaries, use entry_type "retrospective" with tag "session-summary" and structure content as: ## Accomplished, ## Unfinished / Blocked, ## Context for Next Session. REQUIRED: You MUST include project_number. REQUIRED: You MUST include impact_score, trust_score, and validation_status. REQUIRED: You MUST use related_to to anchor the entry to a session summary or nearby context. Requires TEAM_DB_PATH.

Input Schema

Name	Required	Description	Default
`tags`	No	Tags for categorization (kebab-case). Session summaries MUST include "session-summary". DO NOT hallucinate fake tags. Only use tags that genuinely match the content or existing repository vocabulary, domain tags (e.g., "security", "performance") and activity tags (e.g., "refactor", "audit"). [ANTI-HALLUCINATION] MUST be an array of strings, e.g. ["tag1", "tag2"]. NEVER pass a single string.
`author`	No	Override author name (default: auto-detected)
`pr_url`	No
`content`	No	Markdown-formatted entry content. Use ## section headers to organize content. Note: The primary text is stored in the `content` property (not `entry`, `title`, `message`, `name`, `description`, or `text`). For session summaries (entry_type: "retrospective", tagged "session-summary"), MUST use EXACTLY: ## Accomplished, ## Unfinished / Blocked, ## Context for Next Session, ## Commits. Do NOT invent extra top-level sections for session summaries.
`issue_url`	No
`pr_number`	No
`pr_status`	No
`entry_type`	No	Entry type. Use "retrospective" for session summaries, "bug_fix" for bugs, "feature_implementation" for features, "planning" for roadmaps, "technical_note" for implementation notes. Do NOT default to "personal_reflection" unless the entry is genuinely a personal note.	personal_reflection
`session_id`	No	Agent session ID for thread isolation (usually conversation ID).
`trust_score`	No	Heuristic score (0.0-1.0) indicating confidence (0.3-0.5 for unverified, 0.9+ for verified).
`auto_context`	No
`impact_score`	No	Heuristic score (0.0-1.0) indicating blast radius (0.9+ for core architecture, 0.1 for simple docs).
`issue_number`	No
`workspace_id`	No	REQUIRED. The repository name (e.g. adamic). Do not use numeric project IDs or "workspace" as the key.
`project_owner`	No	Owner of the project/task.
`relationships`	No	Optional array of links to previous entries/flags to establish relationships immediately upon creation. Types: "resolves", "depends_on", "implements", "relates_to", "references", "evolves_from"
`workflow_name`	No
`project_number`	No	Numeric project ID (e.g., 1, 14). This is now optional; workspace_id is preferred.
`workflow_run_id`	No
`workflow_status`	No
`significance_type`	No
`validation_status`	No	Current validation status of the entry (passed, none, failed).

Output Schema

Name	Required	Description
`code`	No	Error code (e.g. VALIDATION_ERROR, INTERNAL_ERROR)
`entry`	No
`error`	No	Human-readable error message
`author`	No
`details`	No	Additional error context
`success`	No
`category`	No	Error category (validation, query, connection, internal)
`suggestion`	No	Suggested fix for the error
`recoverable`	No	Whether the error is recoverable
`aggregated_errors`	No	Details of individual errors in a multi-step operation

Schema Changelog

Changes observed during successful MCP inspections.

First observedv9.0.0Nov 2, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations declare a non-read-only, non-destructive, non-idempotent write, so the safety profile is partly covered; the description adds the environment prerequisite (TEAM_DB_PATH) and the collaborator-sharing consequence. It does not say what happens on duplicate entries or how creation is authorized per team, which leaves a real gap for a write tool.

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?

Front-loaded with the when-to-use gate before the formatting rules, and every block (entry_type selection, session-summary template, required fields) is actionable. The three consecutive 'REQUIRED:' sentences are slightly repetitive and could be consolidated without losing meaning.

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

Completeness5/5

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

For a 22-parameter write tool with an output schema available, the description still supplies the operational essentials: prerequisites, format contract, required-field enforcement, type selection, and the alternative tool. Nothing an agent must know before a correct call is missing, aside from edge-case duplicate handling.

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 coverage is 55%, and the description compensates by naming which fields are mandatory (project_number, impact_score, trust_score, validation_status), the required content structure, and the entry_type vocabulary. Caveats: it calls project_number REQUIRED while the schema marks it optional and says workspace_id is preferred, and it references 'related_to' which only exists as a relationType value inside the relationships object, so the naming is imprecise.

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?

States a specific verb and resource (create an entry in the team database) and immediately contrasts it with the sibling personal tool create_entry. An agent can distinguish team_create_entry from create_entry without opening either schema.

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?

Gives an explicit gate ('ONLY use when explicitly requested by the user'), an explicit default ('Default to personal create_entry instead'), plus routing guidance for entry_type and a prescribed shape for session summaries. This is about as prescriptive as a usage section gets.

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

Deploy Server