Skip to main content
Glama
enesjakozh
The-Focus-AI

Mastodon MCP

by The-Focus-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

マストドンMCP

Mastodon と連携するためのツールを提供するモデルコンテキストプロトコルサーバー。現在、オプションのメディア添付ファイル付きのトゥートの作成をサポートしています。

特徴

  • カスタマイズ可能な表示設定とコンテンツ警告付きのトゥートを作成する

  • メディアファイル（画像、動画、音声）をアップロードして添付する

  • メディア添付ファイルに代替テキスト/説明を追加する

  • 1Password CLIを使用した安全な認証情報管理

Related MCP server: MCP Twitter

前提条件

  • Node.js 18歳以上

  • pnpm

  • 1Password CLI ( op ) のインストールと設定

  • MastodonアカウントとAPIアクセストークン

インストール

# Clone the repository
git clone [repository-url]
cd mastodon-mcp

# Install dependencies
pnpm install

# Build the project
pnpm build

構成

このツールを使用するには、1Password に保存されている Mastodon API トークンが必要です。トークンは以下の場所に保管してください。

  • op://Personal/Floss.Social Key/notesPlain

オプションで、環境変数を使用して Mastodon インスタンスの URL を設定することもできます。

export MASTODON_INSTANCE_URL="https://your.instance.social"

設定されていない場合は、デフォルトでhttps://floss.socialになります。

使用法

MCP サーバーを起動します。

pnpm start

サーバーは、次のパラメータを持つ単一のツールmastodon_create_toot公開します。

  • content （必須）: トゥートのテキストコンテンツ

  • visibility : 「公開」、「非公開」、「非公開」、「直接」のいずれか (デフォルト: 「公開」)

  • sensitive : センシティブなコンテンツのブールフラグ（デフォルト: false）

  • spoiler_text : コンテンツの前に表示される警告テキスト（デフォルト: ""）

  • media_file : 添付するメディアファイルへのパス

  • media_description : 添付メディアの代替テキスト/説明

MCP Inspectorの使用例

  1. インスペクターを起動します。

npx @modelcontextprotocol/inspector node dist/mcp-server.js

  1. ブラウザでhttp://localhost:5173を開きます。

  2. 次のようなパラメータを指定してツールを使用します。

{
  "content": "Hello from MCP!",
  "visibility": "public",
  "media_file": "/path/to/image.jpg",
  "media_description": "A beautiful sunset"
}

発達

# Run in development mode with auto-reloading
pnpm dev

# Build the project
pnpm build

# Run the built server
pnpm start

安全

  • コードベースに資格情報がハードコードされていない

  • APIトークンは1Passwordに安全に保存され、そこから取得されます

  • APIレスポンスは、認証情報の偶発的な漏洩を防ぐためにgit-ignoreされます。

ライセンス

ISC

Available Tools

4 tools
mastodon_create_tootB

Create a new toot (status) on Mastodon, optionally with media attachments

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesThe text content of the toot
visibilityNoThe visibility level of the tootpublic
sensitiveNoMark the toot as sensitive content
spoiler_textNoText to be shown as a warning before the actual content
media_fileNoPath to a media file to attach (image, video, or audio)
media_descriptionNoAlt text / description for the attached media
scheduled_atNoOptional ISO 8601 datetime string to schedule the toot for a future time. Examples: 2024-01-01T10:00:00Z, 2024-01-01T10:00:00+01:00

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 the full burden. It mentions creating a toot (implying a write/mutation operation) and optional media attachments, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.

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, efficient sentence that is front-loaded with the core purpose ('Create a new toot on Mastodon') and includes a useful qualifier ('optionally with media attachments'). There is zero waste 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 this is a mutation tool (creating content) with no annotations and no output schema, the description is incomplete. It doesn't address authentication needs, rate limits, error handling, or what the tool returns. For a 7-parameter tool that performs a write operation, more contextual information is necessary to guide an AI agent effectively.

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 schema already documents all 7 parameters thoroughly. The description adds minimal value by mentioning 'optionally with media attachments,' which loosely relates to the media_file and media_description parameters, but doesn't provide additional meaning beyond what the schema specifies. Baseline 3 is appropriate 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.

Purpose5/5

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

The description clearly states the specific action ('Create a new toot') and resource ('on Mastodon'), and distinguishes it from sibling tools by specifying it's for posting content rather than retrieving timelines, tags, or searching. It also mentions the optional media attachments feature.

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

Usage Guidelines2/5

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. The description doesn't mention prerequisites (e.g., authentication needs), when not to use it, or how it differs from other posting methods if they exist. It only states what it does without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mastodon_get_timelineB

Fetch posts from Mastodon timelines (home, public, or local)

ParametersJSON Schema
NameRequiredDescriptionDefault
timeline_typeNoType of timeline to fetchhome
limitNoNumber of posts to fetch (1-40)
max_idNoGet posts older than this ID
since_idNoGet posts newer than this ID

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the fetch action but doesn't mention authentication requirements, rate limits, pagination behavior (beyond max_id/since_id parameters), or what the return format looks like. For a read operation with zero annotation coverage, this leaves significant behavioral gaps unaddressed.

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, efficient sentence that front-loads the core purpose. Every word earns its place - 'fetch posts' establishes action, 'Mastodon timelines' specifies resource, and '(home, public, or local)' provides essential context. No wasted words or redundant information.

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?

For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what authentication is needed, what the return format looks like, how pagination works beyond parameter names, or error conditions. The description provides basic purpose but lacks essential context for effective tool invocation.

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%, with all parameters well-documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides - it mentions timeline types but doesn't explain their differences or usage contexts. Baseline 3 is appropriate when schema does the heavy lifting.

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?

The description clearly states the verb 'fetch' and resource 'posts from Mastodon timelines', specifying three timeline types. It distinguishes from siblings like create_toot (write vs read) and search (specific vs general), though could be more explicit about differentiation from trending_tags. Purpose is clear but sibling differentiation is implied rather than explicit.

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 implies usage context by listing timeline types (home, public, local), suggesting when to use each variant. However, it doesn't explicitly state when to choose this tool over alternatives like search or trending_tags, nor does it provide exclusions or prerequisites. Usage is contextually implied but not explicitly guided.

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. 3 tool updatesv1.0.0
    • Addedmastodon_get_timeline
    • Addedmastodon_get_trending_tags
    • Addedmastodon_search
  2. 1 tool update
    • First observedmastodon_create_toot
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: creating posts, fetching timelines, retrieving trending tags, and searching. There is no overlap in functionality, making it easy for an agent to select the right tool for each task without confusion.

Naming Consistency5/5

All tool names follow a consistent 'mastodon_verb_noun' pattern with snake_case, using clear verbs like create, get, and search. This predictability enhances usability and reduces cognitive load for agents.

Tool Count4/5

With 4 tools, the server is well-scoped for basic Mastodon interactions, covering posting, reading, trending, and searching. It could be slightly expanded for completeness, but the count is reasonable and each tool earns its place.

Completeness3/5

The tools cover core read and write operations (create toots, get timelines/search) but lack update/delete functions for posts, account management, or media handling. This creates minor gaps that agents might need to work around for full lifecycle coverage.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Twitter

    0xhijo
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI models and applications to interact directly with Twitter/X, providing capabilities to create posts, reply to tweets, retrieve user data, and manage account actions.
    13 npm
    11
    MIT

  • Typefully MCP Server

    pepuscz
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI assistants to create and manage Twitter drafts on Typefully, supporting features like thread creation, scheduling, and retrieving published content.
    6
    MIT

  • Twitter MCP Server

    aali-1
    A
    license
    Not graded
    quality
    D
    maintenance
    Model Context Protocol server that enables programmatic interaction with Twitter API, allowing users to post tweets, search for content, and retrieve user timelines through standardized MCP tools.
    17 npm
    MIT