Skip to main content
Glama

DevLog MCP

这是一个 stdio MCP 服务器,用于将 Codex、Claude Code 等 AI 编码代理编写的开发日志发布到现有的 Notion Blog 数据库中。代理负责回顾和正文撰写,而此服务器仅负责输入验证和 Notion 存储。

要求

  • Node.js 20 或更高版本

  • 现有的 Notion Blog 数据库

  • 连接到数据库的 Notion 集成

Related MCP server: Notion MCP Server

安装与构建

npm install
npm test
npm run build

在开发过程中直接运行时,需在当前 shell 中设置环境变量。此项目不会自动读取 .env 文件。

export NOTION_TOKEN="secret_..."
export NOTION_DATABASE_ID="..."
npm run dev

由于 stdio 服务器通过 JSON-RPC 与 MCP 客户端通信,因此在终端中运行时不会输出常规的提示信息。

Notion 设置

  1. 在 Notion 的 Integrations 页面中创建一个 Internal Integration。

  2. 将 Integration token 用作 NOTION_TOKEN。

  3. 在现有 Blog 数据库的连接菜单中添加该 Integration。

  4. 从数据库 URL 中找到 Database ID,并将其用作 NOTION_DATABASE_ID。

数据库属性名称和类型应如下所示:

属性

Notion 类型

默认值

Title

Title

必填

Category

Select

开发

Tags

Multi-select

空列表

PublishedAt

Date

当前日期

Status

Status

published

如果现有数据库的 Select、Multi-select、Status 选项中不存在传递的名称,则根据 Notion 权限和设置,选项创建可能会受到限制。

MCP 工具

服务器提供一个 publish_dev_log 工具。

type PublishDevLogInput = {
  title: string;
  category?: string;
  tags?: string[];
  publishedAt?: string;
  status?: "published" | "draft";
  content: string;
};

正文支持的 Markdown 包括标题 1~3、段落、有序/无序列表、围栏代码块、分隔线。

调用输入示例如下:

{
  "title": "DevLog MCP 첫 구현",
  "tags": ["MCP", "Notion", "TypeScript"],
  "content": "# 오늘의 작업\nNotion 발행 도구를 구현했다.\n\n## 결정\n- MCP는 저장만 담당한다.\n- 회고 작성은 코딩 에이전트가 담당한다."
}

Codex 连接

首先,基于绝对路径注册构建结果。

codex mcp add devlog-mcp \
  --env NOTION_TOKEN=secret_... \
  --env NOTION_DATABASE_ID=... \
  -- node /Users/oddd/workspace/notion/devlog-mcp/dist/index.js

使用以下命令检查注册状态:

codex mcp list

Claude Code 连接

注册为项目范围的 MCP 服务器。

claude mcp add -s project devlog-mcp \
  -e NOTION_TOKEN=secret_... \
  -e NOTION_DATABASE_ID=... \
  -- node /Users/oddd/workspace/notion/devlog-mcp/dist/index.js

使用以下命令检查注册状态:

claude mcp list

连接后,可以请求代理:오늘 개발한 내용을 일지로 정리하고 publish_dev_log로 발행해줘

devlog-mcp

Available Tools

1 tool
publish_dev_log개발 일지 발행B

완성된 개발 일지를 기존 Notion Blog DB에 발행합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNo글 내용을 나타내는 태그
titleYes개발 일지 제목
statusNo발행 상태
contentYesMarkdown 형식의 개발 일지 본문
categoryNo카테고리. 기본값은 개발
publishedAtNo발행일. YYYY-MM-DD 형식

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action (publish to DB) without mentioning idempotency, overwriting behavior, authentication needs, error conditions, or any side effects. This is insufficient for a mutation 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 a single, front-loaded sentence that efficiently conveys the core action and target. Every word is meaningful, and there is no fluff or redundancy.

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

Completeness2/5

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

Given the lack of output schema and annotations, and the presence of 6 parameters including an enum, the description does not provide enough context. It omits return values, error behavior, status effects, and operational prerequisites, leaving the agent underinformed.

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 baseline is 3. The description adds no additional meaning to any parameter beyond what the schema already provides (e.g., format hints, defaults, or usage context).

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

Purpose4/5

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

Description states the verb 'publishes' and the resource 'completed development log' to the 'existing Notion Blog DB'. It is clear what the tool does, but with no sibling tools, differentiation is not applicable, so it scores 4 per rubric.

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

Usage Guidelines3/5

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

The description includes '완성된' (completed), which implies the tool should be used when the development log is finished. However, it provides no explicit when-not-to-use instructions, prerequisites, or alternative tools, so guidance is only implied.

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.

  1. 1 tool updatev0.1.0
    • First observedpublish_dev_log

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion. The tool's purpose is entirely distinct by default.

Naming Consistency5/5

A single tool cannot violate any naming pattern. The name 'publish_dev_log' follows a clear verb_noun convention.

Tool Count3/5

A single tool for a server named 'DevLog MCP' feels thin. While it may serve a specific publishing need, the scope suggests more tools would be expected for full log management.

Completeness2/5

The tool only covers publishing completed logs. Missing basic operations like create, list, update, or delete dev logs, which are likely needed for a complete workflow.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers