Skip to main content
Glama
enesjakozh
The-Focus-AI

Mastodon MCP

by The-Focus-AI
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Mastodon MCP

A Model Context Protocol server that provides tools for interacting with Mastodon. Currently supports creating toots with optional media attachments.

Features

  • Create toots with customizable visibility and content warnings

  • Upload and attach media files (images, videos, audio)

  • Add alt text/descriptions to media attachments

  • Schedule toots for a future time

  • Secure credential management using environment variables or 1Password CLI

Related MCP server: MCP Twitter

Prerequisites

  • Node.js 18+

  • pnpm

  • A Mastodon account and API access token

  • Optionally, 1Password CLI (op) installed and configured if using 1Password for credential management.

Installation

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

# Install dependencies
pnpm install

# Build the project
pnpm build

Configuration

The tool requires a Mastodon API token. You can provide this token in one of the following ways:

  1. Environment Variable (Recommended for simplicity): Set the MASTODON_ACCESS_TOKEN environment variable:

    export MASTODON_ACCESS_TOKEN="your_mastodon_api_token"

  2. 1Password: Store your token at:

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

You can optionally set the Mastodon instance URL via environment variable:

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

If not set, it defaults to https://floss.social.

Usage

Start the MCP server:

pnpm start

The server exposes a single tool mastodon_create_toot with the following parameters:

  • content (required): The text content of your toot

  • visibility: One of "public", "unlisted", "private", or "direct" (default: "public")

  • sensitive: Boolean flag for sensitive content (default: false)

  • spoiler_text: Warning text shown before the content (default: "")

  • media_file: Path to a media file to attach

  • media_description: Alt text/description for the attached media

  • scheduled_at: Optional ISO 8601 datetime to schedule the toot for a future time (e.g., "2024-07-04T10:00:00-07:00")

Example Usage with MCP Inspector

  1. Start the inspector:

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

  1. Open http://localhost:5173 in your browser

  2. Use the tool with parameters like:

{
  "content": "Hello from MCP!",
  "visibility": "public",
  "media_file": "/path/to/image.jpg",
  "media_description": "A beautiful sunset",
  "scheduled_at": "2025-01-01T12:00:00Z"
}

Development

# Run in development mode with auto-reloading
pnpm dev

# Build the project
pnpm build

# Run the built server
pnpm start

Security

  • No credentials are hardcoded in the codebase

  • API tokens can be securely managed via environment variables or retrieved from 1Password.

  • API responses are git-ignored to prevent accidental credential leaks

License

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

  1. 3 tool updatesv1.0.0
    • Addedmastodon_get_timeline
    • Addedmastodon_get_trending_tags
    • Addedmastodon_search
  2. 1 tool update
    • First observedmastodon_create_toot
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

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

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

  • 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.
    17
    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.
    19
    MIT

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/The-Focus-AI/mastodon-mcp'

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