Skip to main content
Glama
deenesjakoruzh
odddman44

DevLog MCP

by odddman44
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

DevLog MCP

This is a stdio MCP server that publishes development logs written by AI coding agents like Codex and Claude Code to an existing Notion Blog Database. The agent is responsible for reflections and writing the content, while this server handles input validation and storage to Notion.

Requirements

  • Node.js 20 or higher

  • Existing Notion Blog Database

  • Notion Integration connected to the Database

Related MCP server: Relentless MCP Server

Installation and Build

npm install
npm test
npm run build

When running directly during development, set the environment variables in the current shell. This project does not automatically read a .env file.

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

stdio servers communicate with MCP clients via JSON-RPC, so no general instructions are printed when running in the terminal.

Notion Setup

  1. Create an Internal Integration in the Notion Integrations screen.

  2. Use the Integration token as NOTION_TOKEN.

  3. Add the Integration via the connection menu of the existing Blog Database.

  4. Find the Database ID in the Database URL and use it as NOTION_DATABASE_ID.

The database property names and types must be as follows.

Property

Notion Type

Default Value

Title

Title

Required

Category

Select

Development

Tags

Multi-select

Empty list

PublishedAt

Date

Current date

Status

Status

published

If the names passed to the Select, Multi-select, and Status options of the existing Database do not exist, option creation may be restricted depending on Notion permissions and settings.

MCP Tools

The server provides a single tool: publish_dev_log.

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

The Markdown supported in the body includes headings 1~3, paragraphs, ordered/unordered lists, fenced code blocks, and horizontal rules.

An example call input is as follows.

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

Connecting to Codex

First, register the build result based on an absolute path.

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

Check the registration status with the following command.

codex mcp list

Connecting to Claude Code

Register as a project-scope MCP server.

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

Check the registration status with the following command.

claude mcp list

After connecting, you can ask the agent: Organize today's development work into a log and publish it using publish_dev_log.

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

  1. 1 tool updatev0.1.0
    • First observedpublish_dev_log
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
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

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/odddman44/devlog-mcp'

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