Allows interaction with a Plurk account to read profile information, alerts, mentions, and thread context, as well as to create new plurks and replies while enforcing safety guardrails such as daily post limits and reply cooldowns.
Click on "Install 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., "@plurk-mcp Check my recent mentions and summarize the latest interactions."
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.
plurk-mcp is a guarded Plurk MCP execution layer for OpenClaw.
It is designed for MCP callers that may operate multiple Plurk accounts and gives an agent a narrow, controlled tool surface for:
reading account, alert, mention, and thread context
creating new plurks
replying only to eligible interactions
enforcing posting guardrails in the execution layer instead of trusting prompt behavior
This repository does not implement editorial strategy, scheduling logic, or campaign decisions. OpenClaw decides what to post and when to post it. plurk-mcp only reads context, executes approved actions, applies safeguards, and records local audit logs.
npm-installable CLI package with dedicated MCP and debug entrypoints
request-scoped Plurk credentials so each tool call can target a different account
Plurk OAuth 1.0a request signing
approved v1 tool surface only:
plurk_get_me
plurk_get_alerts
plurk_get_mentions_context
plurk_get_thread_context
plurk_post
plurk_reply
server-side guardrails:
daily new-post limit
per-thread reply cooldown
reply eligibility checks
local JSONL audit logs
local-only web debug console
Related MCP server: Agent Twitter Client MCP
This project is intentionally restrictive.
Allowed in v1:
read profile, alerts, mentions context, and thread context
create a new plurk
reply to an explicit mention or a reply on a plurk authored by the operator account
Not exposed in v1:
edit plurk
delete plurk
follow user
fan-management actions
unrelated public-thread participation
Node.js >= 22
a caller that can supply a Plurk application key, application secret, access token, and access token secret with each MCP tool call or debug action
If the package is published to npm:
npm install plurk-mcpFor local verification from this repository:
npm install
npm run buildRun MCP mode:
npx plurk-mcpRun debug mode:
npx plurk-mcp-debugYou can also use the main binary with the debug subcommand:
npx plurk-mcp debugOptional:
export PLURK_MCP_TIMEZONE="UTC"
export PLURK_MCP_DAILY_POST_LIMIT="10"
export PLURK_MCP_REPLY_COOLDOWN_MINUTES="15"
export PLURK_MCP_DEBUG_HOST="127.0.0.1"
export PLURK_MCP_DEBUG_PORT="3939"
export PLURK_MCP_DATA_DIR="./data"Meaning of the optional values:
PLURK_MCP_TIMEZONE
Used for daily quota rollover and audit file partitioning.
PLURK_MCP_DAILY_POST_LIMIT
Maximum number of new plurks per local day. Replies do not consume this budget.
PLURK_MCP_REPLY_COOLDOWN_MINUTES
Minimum cooldown between automatic replies in the same thread.
PLURK_MCP_DEBUG_HOST
Debug server bind host. Defaults to 127.0.0.1.
PLURK_MCP_DEBUG_PORT
Debug server port. Must be a positive integer.
PLURK_MCP_DATA_DIR
Root directory for audit logs and policy state.
Every supported MCP tool now requires a credentials object:
{
"credentials": {
"appKey": "your-app-key",
"appSecret": "your-app-secret",
"accessToken": "your-access-token",
"accessTokenSecret": "your-access-token-secret"
}
}This is a breaking change from the original env-bound single-account model.
plurk_get_meReturns the authenticated account profile for the credentials supplied in this call.
plurk_get_alertsReturns recent normalized alerts for the credentials supplied in this call.
plurk_get_mentions_contextReturns recent mention-driven interactions suitable for summarization or reply planning for the credentials supplied in this call.
plurk_get_thread_contextReturns the parent plurk plus normalized replies for a specific thread using the credentials supplied in this call.
plurk_postCreates a new plurk and consumes the daily new-post quota for the authenticated account tied to the supplied credentials.
plurk_replyCreates a reply only when:
the thread belongs to a plurk authored by the operator account, or
the interaction explicitly mentions the operator account
Replies outside that boundary are rejected before the server calls Plurk.
The server enforces these rules regardless of what the agent asks it to do:
new posts are limited to 10 per local day by default for each authenticated account
replies do not consume the daily post budget for that account
replies in the same thread are rate-limited with a default 15 minute cooldown for that account
unsupported high-risk actions are not registered as tools
policy denials and upstream failures are logged locally
The debug console is local-only by default and is intended for operator testing, not public access.
It provides:
sanitized runtime configuration summary
manual credential inputs for app key, app secret, access token, and access token secret
active-account summary for the credentials used by the latest successful action
buttons and forms for approved v1 actions only
normalized JSON responses
policy-denial visibility
recent audit log inspection
Credential-bearing debug actions use JSON POST bodies so secrets do not appear in query strings.
Default URL:
http://127.0.0.1:3939By default the server writes:
data/audit/YYYY-MM-DD.jsonl
data/policy-state.json
The audit log records:
successful reads
successful writes
policy denials
upstream failures
authenticated account attribution when available
Secrets are intentionally excluded from the logged metadata.
{
"mcpServers": {
"plurk": {
"command": "npx",
"args": ["plurk-mcp"],
"env": {
"PLURK_MCP_TIMEZONE": "UTC",
"PLURK_MCP_DAILY_POST_LIMIT": "10",
"PLURK_MCP_REPLY_COOLDOWN_MINUTES": "15"
}
}
}
}Your MCP caller must now inject the Plurk credential bundle into each tool invocation instead of binding one account through process env vars.
Install dependencies:
npm installBuild:
npm run buildType-check:
npm run lintRun tests:
npm testCreate a tarball for local install verification:
npm packsrc/
bin/ CLI entrypoints
config/ environment parsing and runtime config
domain/ shared types and error helpers
integrations/plurk/ OAuth signing, API calls, normalization
services/ policy and application services
storage/ audit and policy-state persistence
transports/mcp/ MCP tool registration
transports/debug/ local web debug console
test/ automated testsThe package, CLI entrypoints, tests, and npm artifact verification are in place.
What still depends on your real environment:
end-to-end verification against live Plurk credentials
any tuning of rate limits or upstream response handling discovered during real usage
Return recent normalized alert events for the credentials supplied in this call.
| Name | Required | Description | Default |
|---|---|---|---|
| credentials | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It adds useful context with 'recent' (temporal scope) and 'normalized' (data format), but omits critical behavioral details such as the time window for 'recent', pagination behavior, sorting order, or rate limit implications of the OAuth credentials.
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 that places the action and resource at the front. However, the phrase 'for the credentials supplied in this call' is slightly redundant (credentials are inherent to the call) and could be replaced with more useful parameter or behavioral documentation.
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 complex nested credentials object (4 required fields), the limit parameter with constraints (1-100, default 20), lack of annotations, and absence of an output schema, the description is insufficient. It fails to prepare the agent for the OAuth credential structure, pagination limits, or the structure of normalized alert events.
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 schema has 0% description coverage, requiring the description to compensate. While it acknowledges the 'credentials' parameter ('for the credentials supplied in this call'), it fails to document the four required nested OAuth fields (appKey, appSecret, etc.) or explain their semantics. It completely omits the 'limit' parameter, leaving both top-level parameters effectively undocumented.
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 provides a clear verb ('Return') and resource ('recent normalized alert events'), establishing what the tool does. However, it does not explicitly differentiate 'alerts' from sibling tools like 'mentions' or 'threads' (plurk_get_mentions_context, plurk_get_thread_context), which could help an agent select the correct endpoint.
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 plurk_get_mentions_context or plurk_get_me. There is no mention of prerequisites, required user states, or conditions that would indicate when alerts are the appropriate resource to fetch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the authenticated Plurk account profile for the credentials supplied in this call.
| Name | Required | Description | Default |
|---|---|---|---|
| credentials | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. While 'Return' implies a read-only operation, the description fails to disclose error behaviors (invalid credentials), rate limits, or what profile fields are returned. It mentions 'credentials supplied' but doesn't clarify these are OAuth 1.0a tokens requiring specific procurement steps.
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 efficient sentence that front-loads the action ('Return') and resource ('authenticated Plurk account profile'). No redundant phrases, though extreme brevity contributes to informational gaps.
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 zero schema descriptions, no output schema, complex nested authentication requirements, and presence of sibling tools, the description is incomplete. It should explain the OAuth credential structure, indicate what profile data is returned, and clarify error conditions for invalid authentication.
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% for the four nested credential fields (appKey, appSecret, accessToken, accessTokenSecret). The description mentions 'credentials supplied' which maps to the parameter name, but provides no semantic explanation for the OAuth credential components, their format, or how to obtain them, leaving the complex nested object effectively undocumented.
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 'Return[s] the authenticated Plurk account profile' with specific resource (account profile) and action (Return/Retrieve). It implicitly distinguishes from siblings (get_alerts, get_thread_context, post, reply) by specifying this retrieves the user's own profile rather than content or alerts.
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 provides no guidance on when to use this tool versus siblings (e.g., when needing user ID or display name versus getting mentions), nor does it mention prerequisites like required OAuth permissions or token validity checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent mention-driven interactions and context suitable for summarization or reply planning for the supplied credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| credentials | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It mentions 'recent' and 'interactions' but fails to state whether this is read-only (implied only by 'Return'), what 'recent' means temporally, rate limits, or what the return format contains.
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 with reasonable density. 'Suitable for summarization or reply planning' adds value, though 'for the supplied credentials' is somewhat redundant with the required schema parameter. Adequately front-loaded but not exceptional.
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 zero annotations, no output schema, and 0% parameter documentation, the description should work harder to explain parameter semantics, differentiate from siblings (get_alerts vs. mentions), and disclose behavioral traits. It covers basic purpose but leaves critical gaps unfilled.
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 has 0% description coverage, yet the description only mentions 'credentials' in passing without explaining the OAuth structure (4 nested fields) or the 'limit' parameter (default 20, max 100). Insufficient compensation for the undocumented 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?
Clear verb ('Return') and resource ('mention-driven interactions and context'). Specifies the domain (mentions vs. general alerts or threads), though it could more explicitly contrast with siblings like plurk_get_alerts or plurk_get_thread_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?
Provides implied usage via 'suitable for summarization or reply planning,' giving the agent a hint about when to invoke it. However, lacks explicit when-not-to-use guidance or named alternatives (e.g., 'use plurk_get_thread_context instead for specific conversation threads').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the parent plurk and normalized replies for a specific thread using the supplied credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| credentials | Yes | ||
| plurkId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses 'normalized replies' processing behavior and implies credential-based auth. However, lacks details on what 'normalized' means, response structure, rate limits, or pagination given zero annotations provided.
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, front-loaded with action verb. Every phrase earns its place: 'normalized' signals processing, 'parent plurk' distinguishes from replies, 'supplied credentials' establishes auth requirement.
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?
Adequate basic description but insufficient given complexity: nested credential object with 4 undocumented fields, no output schema, and no annotations. Missing crucial details like what constitutes a valid plurkId or expected response format.
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 coverage, description compensates partially: 'supplied credentials' maps to auth object and 'specific thread' implies plurkId identifies the thread. However, fails to document the 4 required credential sub-fields (appKey, appSecret, etc.) or plurkId value format.
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?
Specific verb 'Return' with clear resource 'parent plurk and normalized replies' and scope 'specific thread'. Distinct from siblings: plurk_post/reply are write operations, plurk_get_alerts/mentions_context retrieve different data types.
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 vs plurk_get_mentions_context or other retrieval tools. No mention of prerequisites like needing a valid plurkId from a previous search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Plurk post for the supplied credentials while enforcing the server-side daily post quota.
| Name | Required | Description | Default |
|---|---|---|---|
| credentials | Yes | ||
| content | Yes | ||
| qualifier | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully notes the quota enforcement mechanism, but omits other critical mutation behaviors: error handling when quotas are exceeded, whether the operation is idempotent, and what side effects occur.
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 is front-loaded with the action ('Create') and avoids redundancy. However, given the complex nested auth schema and 0% coverage, extreme brevity becomes a liability rather than a virtue.
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 write operation with complex authentication, platform-specific jargon ('qualifier'), and no output schema, the description is incomplete. It misses credential field explanations, valid qualifier values, return structure, and error scenarios essential for correct 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%, yet the description fails to compensate. It vaguely references 'supplied credentials' without explaining the four nested OAuth fields (appKey, appSecret, etc.), completely ignores the 'qualifier' parameter (a Plurk-specific concept), and provides no formatting guidance for 'content'. This is a significant documentation gap.
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 uses a specific verb ('Create') and resource ('Plurk post'), clearly distinguishing it from the sibling 'get' tools (alerts, me, mentions, thread) and the 'reply' tool. It establishes this as the primary content creation entry point.
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?
It mentions the 'server-side daily post quota' which provides implicit usage context (rate limiting exists), but it lacks explicit guidance on when to use this versus plurk_reply or prerequisites like required OAuth scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to an eligible Plurk thread for the supplied credentials when it is an owned thread or an explicit mention.
| Name | Required | Description | Default |
|---|---|---|---|
| credentials | Yes | ||
| plurkId | Yes | ||
| content | Yes | ||
| qualifier | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It successfully conveys the write-operation nature ('reply') and critical eligibility constraints, but fails to address error behavior (what happens if the thread is ineligible), rate limits, or side effects. The mention of credentials implies authentication 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 a single sentence achieving brevity, but suffers from slightly awkward phrasing ('for the supplied credentials' rather than 'using'). The eligibility clause is grammatically attached to the credentials rather than the reply action, creating minor parsing friction. Every word is functional but the structure could be clearer.
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—including a nested OAuth credentials object, 4 parameters with 0% schema coverage, no output schema, and platform-specific eligibility rules—the single-sentence description is insufficient. It lacks explanation of return values, error conditions, the purpose of the 'qualifier' field, and Plurk-specific behavioral context needed for safe 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?
With 0% schema description coverage, the description must compensate significantly but falls short. While it implicitly references 'credentials' and the reply action suggests 'content' and 'plurkId' usage, it provides no explanation for the 'qualifier' parameter (which is optional but undocumented) and no format guidance for any parameter. The complex nested credentials object particularly requires description support that is absent.
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 identifies the specific action (reply) and resource (Plurk thread), and includes eligibility criteria (owned thread or explicit mention) that implicitly distinguish it from the sibling 'plurk_post' tool. However, it could more explicitly contrast with 'plurk_post' to make the distinction clearer.
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 provides eligibility constraints specifying when the tool can be used (owned threads or explicit mentions), which serves as contextual guidance. However, it lacks explicit guidance on when NOT to use this tool versus alternatives like 'plurk_post', and omits prerequisites beyond credential requirements.
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 clearly distinct purpose: retrieving alerts, profile data, mentions context, thread context, creating a post, and replying to a thread. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent 'plurk_verb_noun' pattern (e.g., plurk_get_alerts, plurk_post). This uniformity in naming makes the tool set predictable and easy to understand.
With 6 tools, this server is well-scoped for interacting with Plurk's social platform. It covers key operations like reading data and posting content without being overly sparse or bloated.
The tool set provides good coverage for core Plurk interactions, including reading alerts, profile, mentions, threads, and posting/replies. A minor gap might be the lack of update or delete operations for posts, but the essential workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Remote MCP server for The Colony — a social network for AI agents (posts, DMs, search, marketplace).
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
PerfectPost is a LinkedIn content management platform. This MCP server gives AI assistants read and write access to a user's PerfectPost account: published posts with their engagement analytics, drafts lifecycle (create / edit / schedule), and LinkedIn profile data.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/congcongfu/plurk-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
