Skip to main content
Glama

mastodon_get_timeline

Fetch posts from Mastodon timelines including home, public, or local feeds to monitor social activity and content.

Instructions

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

Input Schema

TableJSON 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

Implementation Reference

  • The handler function that implements the core logic of the 'mastodon_get_timeline' tool: processes parameters, fetches timeline data via MastodonClient methods, formats the response as a text list of posts, and returns it in MCP content format.
    async (params: TimelineParams) => {
      const timelineParams = {
        limit: params.limit,
        max_id: params.max_id,
        since_id: params.since_id,
      };
    
      let posts;
      switch (params.timeline_type) {
        case "home":
          posts = await client.getHomeTimeline(timelineParams);
          break;
        case "public":
          posts = await client.getPublicTimeline(timelineParams);
          break;
        case "local":
          posts = await client.getLocalTimeline(timelineParams);
          break;
        default:
          throw new Error(`Unknown timeline type: ${params.timeline_type}`);
      }
    
      const summary = `Found ${posts.length} posts from ${params.timeline_type} timeline`;
      const postsList = posts.map((post, index) => {
        const reblogInfo = post.reblog ? ` (reblogged from @${post.reblog.account.acct})` : "";
        const mediaInfo = post.media_attachments.length > 0 ? ` [${post.media_attachments.length} media]` : "";
        return `${index + 1}. @${post.account.acct}${reblogInfo}: ${post.content.replace(/<[^>]*>/g, '').substring(0, 100)}...${mediaInfo}\n   Posted: ${new Date(post.created_at).toLocaleString()}\n   URL: ${post.url}`;
      }).join('\n\n');
    
      return {
        content: [
          {
            type: "text",
            text: `${summary}\n\n${postsList}`,
          },
        ],
      };
    }
  • Zod schema defining the input parameters for the mastodon_get_timeline tool: timeline_type (home/public/local), limit (1-40), max_id, since_id.
    const TimelineSchema = z.object({
      timeline_type: z
        .enum(["home", "public", "local"])
        .describe("Type of timeline to fetch")
        .default("home"),
      limit: z
        .number()
        .min(1)
        .max(40)
        .describe("Number of posts to fetch (1-40)")
        .default(20)
        .optional(),
      max_id: z
        .string()
        .describe("Get posts older than this ID")
        .optional(),
      since_id: z
        .string()
        .describe("Get posts newer than this ID")
        .optional(),
    });
  • MCP server tool registration for 'mastodon_get_timeline', including name, description, input schema reference, and inline handler function.
    server.tool(
      "mastodon_get_timeline",
      "Fetch posts from Mastodon timelines (home, public, or local)",
      TimelineSchema.shape,
      async (params: TimelineParams) => {
        const timelineParams = {
          limit: params.limit,
          max_id: params.max_id,
          since_id: params.since_id,
        };
    
        let posts;
        switch (params.timeline_type) {
          case "home":
            posts = await client.getHomeTimeline(timelineParams);
            break;
          case "public":
            posts = await client.getPublicTimeline(timelineParams);
            break;
          case "local":
            posts = await client.getLocalTimeline(timelineParams);
            break;
          default:
            throw new Error(`Unknown timeline type: ${params.timeline_type}`);
        }
    
        const summary = `Found ${posts.length} posts from ${params.timeline_type} timeline`;
        const postsList = posts.map((post, index) => {
          const reblogInfo = post.reblog ? ` (reblogged from @${post.reblog.account.acct})` : "";
          const mediaInfo = post.media_attachments.length > 0 ? ` [${post.media_attachments.length} media]` : "";
          return `${index + 1}. @${post.account.acct}${reblogInfo}: ${post.content.replace(/<[^>]*>/g, '').substring(0, 100)}...${mediaInfo}\n   Posted: ${new Date(post.created_at).toLocaleString()}\n   URL: ${post.url}`;
        }).join('\n\n');
    
        return {
          content: [
            {
              type: "text",
              text: `${summary}\n\n${postsList}`,
            },
          ],
        };
      }
    );
  • Supporting helper methods in MastodonClient class: getHomeTimeline, getPublicTimeline, and getLocalTimeline, which perform the actual API requests to fetch timeline data used by the tool handler.
    // Timeline methods
    async getHomeTimeline(params: TimelineParams = {}): Promise<MastodonStatus[]> {
      const queryParams = this.buildQueryParams(params);
      return this.request<MastodonStatus[]>(`/api/v1/timelines/home${queryParams}`);
    }
    
    async getPublicTimeline(params: TimelineParams = {}): Promise<MastodonStatus[]> {
      const queryParams = this.buildQueryParams(params);
      return this.request<MastodonStatus[]>(`/api/v1/timelines/public${queryParams}`);
    }
    
    async getLocalTimeline(params: TimelineParams = {}): Promise<MastodonStatus[]> {
      const localParams = { ...params, local: true };
      const queryParams = this.buildQueryParams(localParams);
      return this.request<MastodonStatus[]>(`/api/v1/timelines/public${queryParams}`);
    }
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.

Install Server

Other Tools

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