Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pplog MCP Server search poems about cherry blossoms"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
日本語 | English
pplog の公式 MCP(Model Context Protocol)サーバー(STDIO Transport 版)
AI アシスタントとポエム共有サービス pplog をつなぐ MCP サーバーです。Model Context Protocol 経由で、AI アシスタントから pplog のポエムを読んだり、検索・投稿ができます。
Related MCP server: limitless-ai-mcp-server
get-poem - ポエムを ID で取得
search-poems - ポエムを検索（日付絞り込み、AND/OR 検索、除外検索などに対応）
create-poem - 新しいポエムを投稿
MCP クライアントの設定ファイルに以下を追加します：
PPLOG_ACCESS_TOKEN: アクセストークン
claude_desktop_config.json への追加方法：
{
"mcpServers": {
"pplog": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"PPLOG_ACCESS_TOKEN",
"ghcr.io/esaio/pplog-mcp-server"
],
"env": {
"PPLOG_ACCESS_TOKEN": "your_access_token"
}
}
}
}{
"mcpServers": {
"pplog": {
"command": "/Users/your-username/.nodenv/shims/npx",
"args": ["@esaio/pplog-mcp-server"],
"env": {
"PPLOG_ACCESS_TOKEN": "your_access_token"
}
}
}
}注意:
/path/to/your/nodeはwhich nodeで調べたパスに置き換えてください。
pplog - ポエム共有サービス pplog
Model Context Protocol - MCP の詳細
Claude Desktop - MCP 対応の AI アシスタント
🐛 Issues: GitHub Issues
Made with ❤️ by the esa team
Creates a pplog poem: a casual short note (not literary verse). Posting hides your previous poem from other readers.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Poem content (first line is title, rest is body) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations flag destructiveHint=true, but the description goes beyond that by spelling out the concrete consequence: 'Posting hides your previous poem from other readers.' That explains what is effectively destroyed/overwritten, which the annotation alone cannot convey. It stops short of covering permissions or whether the hidden poem is recoverable.
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?
Two tight sentences, zero filler, with the core action first and the side effect second. Every clause carries information an agent needs.
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?
For a single-parameter mutation with annotations covering safety and no output schema, the description supplies purpose, domain meaning, and the destructive side effect. Return behavior is unstated, but with no output schema that is a minor gap rather than a blocking one.
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?
Only one parameter with 100% schema description coverage, so the schema already explains 'first line is title, rest is body'. The description adds nothing about the content format or any constraints, which is the expected baseline 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Creates) and resource (pplog poem), and immediately disambiguates the domain term with 'a casual short note (not literary verse)'. This lets an agent distinguish it from the read-only siblings get-poem and search-poems without opening any 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?
Usage is only implied: an agent can infer you call this to post a poem, but the description never states when to prefer it over the siblings (e.g., after reading with get-poem) or any prerequisite such as having an existing account/poem. No explicit when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a poem from pplog by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Poem ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds no behavioral context beyond that — no note on missing-ID handling, error behavior, or visibility of the poem, so it contributes essentially nothing over the structured fields.
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?
A single short sentence that front-loads the action and resource with zero filler. Nothing is extraneous and no important element is buried.
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?
For a one-parameter read tool with a full safety annotation set and no output schema, the description covers what an agent needs to invoke it correctly. It could mention behavior when the ID is not found, but the omission is minor at this level of complexity.
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 a single parameter at 100% schema description coverage, the schema already documents 'id' as the Poem ID. The description's 'by ID' merely restates that, adding no format, source, or validation detail beyond the schema, so the baseline 3 applies.
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 states a specific verb (retrieves), resource (poem), source system (pplog), and access key (by ID), so an agent can distinguish it from create-poem and search-poems. It does not name those siblings explicitly, but the retrieval-by-ID framing is unambiguous.
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?
The phrase 'by ID' implies this is the tool to use when you already have a known poem ID rather than a query, which implicitly separates it from search-poems. However, there is no explicit when-to-use/when-not-to-use guidance or named alternative, so usage is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for poems in pplog with advanced query syntax support.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (starting from 1). If omitted, retrieves the first page. | |
| keyword | No | Search query for poems. Supports advanced search patterns: ## Important Note for Relative Date Queries: **CRITICAL: Always get today's actual date from the system before processing relative date queries (e.g., "today", "yesterday", "last week", "recent"). Convert relative terms to absolute dates for accurate searching.** ## Query Syntax: - Basic search: "keyword" for partial match, "exact phrase" for exact match - Negative search: "-keyword" to exclude - Date search: - date:2023 (year), date:2023-10 (month), date:2023-10-11 (day) - date>2023-10-01, date>=2023-10-01, date<2023-10-01, date<=2023-10-01 - before:2023-10-01, after:2023-10-01 - Logical operators: - AND (case-insensitive) or just space - OR (case-insensitive) - Grouping: (keyword1 OR keyword2) AND keyword3 Empty string returns all your poems. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that advanced query syntax is supported, which is a capability note rather than behavioral context (no pagination, result-limit, or scoping disclosure) — adequate but thin against the lower bar set by annotations.
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?
A single front-loaded sentence with zero filler. Short, but nothing in it is redundant or padded.
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?
For a two-parameter read-only search with a fully documented schema and no output schema, the definition is functional but omits result shape/pagination behavior tied to the "page" parameter and any note that empty input returns everything. Complete enough to call, not complete enough to set expectations.
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 100%, and the keyword parameter's schema entry is extremely detailed (date operators, boolean logic, grouping, empty-string behavior), so the schema fully carries parameter meaning. The description adds nothing beyond it, which is the baseline-3 case.
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?
States a specific verb and resource ("Searches for poems") and names the target system (pplog), so the operation is unambiguous. It does not, however, distinguish itself from siblings get-poem or create-poem, leaving the retrieve-vs-create-vs-search distinction to the names alone.
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?
The description gives no when-to-use guidance, no mention of when a search is preferable to get-poem, and no note about the no-argument/empty-keyword behavior. "Advanced query syntax support" hints at capability but not at selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.4.1create-poemget-poemsearch-poemsScored across 3 tools
Each tool has a clearly distinct purpose: get by ID, search by query, and create a new poem. There is no overlap that would cause misselection.
All names follow a verb-noun hyphenated pattern (get-poem, search-poems, create-poem), but the plural/singular inconsistency (search-poems vs. get-poem/create-poem) is a minor deviation.
Three tools is a small but focused set for a simple casual-note service. It is slightly under what might be expected, but each tool earns its place and the scope is well-defined.
Core operations (create, get by ID, search) are covered. Deleting or listing poems is absent, but the create tool's implicit update behavior and search likely cover most agent needs; the gap is minor.
Your portable context layer — load it into any AI.
ppl: the personal CRM for AI agents. Structured relationship memory over hosted MCP.
Connect AI agents to Replynodes over the Model Context Protocol.
Shared, versioned context that humans and AI agents can publish, review, annotate, and continue.
