Skip to main content
Glama

search_linkedin_posts

Find LinkedIn posts using keywords, content types, authors, industries, and date filters to gather relevant professional content and insights.

Instructions

Search for LinkedIn posts with various filters like keywords, content type, authors, etc.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
author_industriesNoIndustry URN, can be obtained in /linkedin/search/industries. Or industry name.
author_titleNoAuthor job title.
authorsNoAuthors URN of posts
content_typeNoDesired content type
countYesMax result count
date_postedNoDate postedpast-month
keywordsNoAny keyword for searching in the post. For exact search put desired keywords into brackets
mentionedNoMentioned users URN in posts
sortNoSort typerelevance
timeoutNoMax scrapping execution timeout (in seconds)

Implementation Reference

  • The core handler function that prepares the request payload, makes an API call to the AnySite LinkedIn search posts endpoint, processes the response, logs activity, and handles errors appropriately.
    async ({ keywords, count, timeout, sort, date_posted }) => {
      const requestData: any = { timeout, keywords, count };
      if (sort) requestData.sort = sort;
      if (date_posted) requestData.date_posted = date_posted;
      log("Starting LinkedIn posts search with:", JSON.stringify(requestData));
      try {
        const response = await makeRequest(API_CONFIG.ENDPOINTS.LINKEDIN_SEARCH_POSTS, requestData);
        log(`Search complete, found ${response.length} results`);
        return {
          content: [{ type: "text", text: JSON.stringify(response, null, 2) }]
        };
      } catch (error) {
        log("LinkedIn search posts error:", error);
        return {
          content: [{ type: "text", text: `LinkedIn search posts API error: ${formatError(error)}` }],
          isError: true
        };
      }
    }
  • Zod schema defining the input parameters for the search_linkedin_posts tool, including descriptions and defaults.
    {
      keywords: z.string().describe("Search keywords"),
      count: z.number().default(10).describe("Max results"),
      timeout: z.number().default(300).describe("Timeout in seconds"),
      sort: z.string().optional().describe("Sort order"),
      date_posted: z.string().optional().describe("Date filter")
  • src/index.ts:468-496 (registration)
    Complete MCP server.tool registration for 'search_linkedin_posts', including name, description, input schema, and handler implementation.
      "search_linkedin_posts",
      "Search LinkedIn posts with keywords and filters",
      {
        keywords: z.string().describe("Search keywords"),
        count: z.number().default(10).describe("Max results"),
        timeout: z.number().default(300).describe("Timeout in seconds"),
        sort: z.string().optional().describe("Sort order"),
        date_posted: z.string().optional().describe("Date filter")
      },
      async ({ keywords, count, timeout, sort, date_posted }) => {
        const requestData: any = { timeout, keywords, count };
        if (sort) requestData.sort = sort;
        if (date_posted) requestData.date_posted = date_posted;
        log("Starting LinkedIn posts search with:", JSON.stringify(requestData));
        try {
          const response = await makeRequest(API_CONFIG.ENDPOINTS.LINKEDIN_SEARCH_POSTS, requestData);
          log(`Search complete, found ${response.length} results`);
          return {
            content: [{ type: "text", text: JSON.stringify(response, null, 2) }]
          };
        } catch (error) {
          log("LinkedIn search posts error:", error);
          return {
            content: [{ type: "text", text: `LinkedIn search posts API error: ${formatError(error)}` }],
            isError: true
          };
        }
      }
    );
  • API endpoint constant used by the tool handler for LinkedIn posts search.
    LINKEDIN_SEARCH_POSTS: "/api/linkedin/search/posts",
  • TypeScript interface defining the expected arguments for LinkedIn search posts, providing type safety and documentation.
    export interface LinkedinSearchPostsArgs {
      timeout?: number;
      keywords?: string;
      sort?: "relevance";
      date_posted?: "past-month" | "past-week" | "past-24h";
      content_type?: "videos" | "photos" | "jobs" | "live_videos" | "documents" | null;
      mentioned?: string[] | null;
      authors?: string[] | null;
      author_industries?: string[] | string | null;
      author_title?: string | null;
      count: number;
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'various filters' but doesn't describe important behavioral aspects: whether this is a read-only operation, what happens when no results are found, whether results are paginated, rate limits, authentication requirements, or what the output format looks like. The description is too minimal for a search tool with 10 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point. It's appropriately sized for a search tool, though it could potentially benefit from a bit more context given the complexity of the parameters. There's no wasted language 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?

For a search tool with 10 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (post objects, metadata, error conditions), doesn't mention performance characteristics or limitations, and provides no context about how the search actually works (API calls, scraping, etc.). The 'timeout' parameter suggests scraping behavior that isn't mentioned in the description.

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 10 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'various filters like keywords, content type, authors, etc.' but doesn't provide additional context about parameter interactions, default behaviors, or practical usage examples. This meets the baseline for high schema coverage.

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 tool's purpose: 'Search for LinkedIn posts with various filters'. It specifies the resource (LinkedIn posts) and action (search with filters), making the verb+resource combination explicit. However, it doesn't distinguish this tool from sibling tools like 'search_linkedin_users' or 'search_reddit_posts' beyond mentioning 'LinkedIn posts'.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this search tool should be preferred over 'get_linkedin_user_posts' (which retrieves posts from specific users) or 'search_reddit_posts' (which searches a different platform). There's no context about use cases, prerequisites, or limitations.

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/anysiteio/hdw-mcp-server'

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