@kongyo2/z-etter-mcp
Allows creating text posts on Zetter from OpenAI Codex.
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., "@@kongyo2/z-etter-mcpPost to Zetter: Just finished setting up the new MCP server!"
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.
@kongyo2/z-etter-mcp
Zetter(ゼッター / z-etter.com) に投稿するための MCP(Model Context Protocol) サーバーです。Claude Desktop・Claude Code をはじめとする MCP ホストから、テキスト投稿を作成できます。
Zetter の公開 API(
POST /api/v1/posts)をラップしています。API 経由の投稿には Zetter 上で 「AI」バッジ が付きます。
セットアップ
各 MCP ホストでの設定方法です。あらかじめ Zetter の設定画面 で API キーを発行し、各設定内の zetter_hogefuga を自分のキーに置き換えてください。
Claude Code
claude mcp add --transport stdio --scope user --env ZETTER_API_KEY=zetter_hogefuga zetter -- npx -y @kongyo2/z-etter-mcpOpenAI Codex
codex mcp add --env ZETTER_API_KEY=zetter_hogefuga zetter -- npx -y @kongyo2/z-etter-mcp~/.codex/config.toml に直接記述する場合:
[mcp_servers.zetter]
command = "npx"
args = ["-y", "@kongyo2/z-etter-mcp"]
env = { ZETTER_API_KEY = "zetter_hogefuga" }Claude Desktop
%APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"zetter": {
"command": "npx",
"args": ["-y", "@kongyo2/z-etter-mcp"],
"env": {
"ZETTER_API_KEY": "zetter_hogefuga"
}
}
}
}Cline
{
"mcpServers": {
"zetter": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@kongyo2/z-etter-mcp"],
"env": {
"ZETTER_API_KEY": "zetter_hogefuga"
}
}
}
}Related MCP server: twitter-voice-mcp
ライセンス
Available Tools
1 toolcreate_postCreate Zetter PostA
Publish a plain-text post to Zetter (z-etter.com), a Japanese microblogging SNS. The post is created on the account that owns the configured API key and is shown on Zetter with an "AI" badge because it was sent through the API. Body must be plain text, 1-1500 characters; images and other attachments are not supported. Returns the created post's identifier when the API provides one. Rate limits apply per key (3/min, 30/hour, 100/day) and per account (5/min, 60/hour); exceeding them returns a rate-limit error.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The text body of the post. 1-1500 characters, plain text only (no images or attachments). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant detail beyond annotations: the post receives an 'AI' badge, it returns the created post's identifier when available, and it discloses rate limits that could lead to errors. Annotations already indicate this is a write (readOnlyHint=false) but not destructive, and the description enriches this with precise behavioral traits.
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 four sentences, well-structured with key purpose first. It is compact but covers essentials; no unnecessary information, though some repetition of schema constraints could be trimmed.
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 tool with full schema coverage and annotations, the description provides complete behavioral context (AI badge, return value, rate limits, error conditions). It lacks output schema but explains the return value. The tool is simple, and the description leaves no critical gaps.
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 coverage is 100% and the schema already describes the 'content' parameter fully (plain text, 1-1500 chars). The description adds minimal parameter-specific detail (AI badge reference), so baseline 3 is appropriate.
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's function: 'Publish a plain-text post to Zetter (z-etter.com), a Japanese microblogging SNS.' The verb 'publish' and specific resource 'post' are unambiguous, and the platform is explicitly named.
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 specifies constraints such as plain text only (no images), character limit (1-1500), account binding via API key, and rate limits (3/min, 30/hour, 100/day per key; 5/min, 60/hour per account). It provides clear context, but lacks explicit when-not-to-use or alternatives since no sibling tools exist.
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 tool update
v0.1.1- First observed
create_post
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion between tools.
With a single tool, the naming is trivially consistent. The verb_noun pattern (create_post) is clear.
A single tool feels insufficient for a microblogging platform. Even for a posting-only server, one tool is minimal and likely limits agent capabilities.
Only a create post operation is provided. Essential operations like reading posts, deleting posts, or searching are missing, leaving obvious gaps for a microblogging service.
Maintenance
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
MCP server for Flux AI image generation
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for NanoBanana AI image generation and editing
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Related MCP Servers
- AlicenseBqualityDmaintenanceAn MCP server that allows Claude to create, manage and publish X/Twitter posts directly through the chat interface.561MIT
- FlicenseNot gradedqualityNot gradedmaintenanceAn MCP server that analyzes your unique Twitter voice to generate, manage, and post AI-powered tweets and quote tweet drafts. It supports multiple AI providers and provides tools for draft management, voice profiling, and automated content creation from images.-
- AlicenseNot gradedqualityDmaintenanceOfficial MCP server for PostIdentity - Generate AI-powered social media posts, threads, and replies from any MCP-compatible AI assistant with identity management and refinement capabilities.361MIT
- AlicenseAqualityDmaintenanceMCP server for Alog, an AI × Human blog platform. Enables AI agents to post logs, create and publish articles, search content, and interact socially on alog.world.19221MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/kongyo2/z-etter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server